Testsudo v1.0.0

Product Description

Welcome to Testsudo, a one-stop testing suite enabling you to test your project's frontend, backend, and security performance!

With a simple CLI command, Testsudo will perform some testing magic and give you a range of metrics for your project on a compatible web application. Rather than searching for 3 separate performance optimization tools, Testsudo abstracts that away into a single command.

Testsudo allows you to:

• Track multiple projects on the web application, each with its own unique Dashboard
• Test each page of your project and drills down into the metrics by path

Instructions on using the Testsudo Module

1. Sign up and login to Testsudo http://testsudo.com.

2. Create a new project and copy the Project ID.

3. On your terminal, run npm i @testsudo/testsudo.

4. Create a testsudoConfig.js in the root directory of your consuming app.

module.exports = {
    lighthouseUrl: <insert url of what project you want to test>,
    projectID: <insert project id from the web app in quotes>,
};

4. In the consuming app’s server.js file, add the following code immediately after app is initialized (const app = express()):

If using CommonJS:

const testsudo = require(‘testsudo’);
const testsudoConfig = require(‘../testsudoConfig.js’); // make sure this is the actual location of testsudoConfig.js
testsudo.initializeTestsudo(app, testsudoConfig);

If using ES6+:

import testsudo from 'testsudo';
import testsudoConfig from '../testsudoConfig.js'; // make sure this is the actual location of testsudoConfig.js
testsudo.initializeTestsudo(app, testsudoConfig);

5. Run your development environment as you would normally would (e.g., npm run dev).

6. Review your project dashboard on Testsudo http://testsudo.com

Frontend Testing

Lighthouse metrics

Of 05/13/2024 the latest version of Lighthouse is 12.

Core Web Vitals:

Performance

Lighthouse 10 Audit Scoring System

Understanding LHR (Lighthouse Result Object)

acronym	audit categories	Weight	Brief Description
FCP	First Contenful Paint	10%	Marks the time at which the first text or image is painted
SI	Speed Index	10%	Shows how quickly the contents of a page are visibly populated
TBT	Total Blocking Time	25%	Sum of all time periods between FCP and Time to Interactive (i.e., the amount of time it takes for the page to be fully interactive)
LCP	Largest Contenful Paint	30%	Marks the time at which the largest text or image is painted
CLS	Cumulative Layout Shift	25%	Measures the movement of visible elements within the viewport

|

[Accessibility] (https://developer.chrome.com/docs/lighthouse/accessibility/scoring)

Each metrics are pass/fail, weighted score of importance from 1-10.

Some examples of Accessiblity Metrics:

description	weight
Button has accessible names	(10)
No Forms have multiple lablels	(3)
Links must have descernible text	(7)
Image buttons must have alternate text	(10)

Best Practices

Each set of metrics are just general guidelines of how to use good practices to make your code run smoothly

Backend Testing

Different types of backend testing: Load

• Benchmarking test
• Should be the first test you run.
• To assess current performance of concurrent users/request per second.
  • Performance of system under typical and peak load
  • To have a barometer to compare against for the future.
  • Great for CI/CD.
  • Use the load test to test against other test i.e. spike and stress.

Spike (strength training)

• sSmilar to stress test but instead of ramping the test in steady increament over relatively long time, but 'spikes' it over a very short amount of time

Stress (endurance training)

• Limits of the system (verify reliablity and stability)
• How far can we push it under extreme condition
• What is the max capacity of users/throughput
• What is the breaking point and its failure mode
• Will the system need a manual intervention to recover after the stress test is complete

Soak (endurance training or maybe long term review)

• Reliablity over long term, usually the longest test, usually hours
  • Testing for bugs and memory leaks -\ can lead to crash/restarts
  • Verify that expected application restarts don't lose requests
  • Find bugs related to race-conditions that appear sporadically
  • Makes sure the DB doesn't exhaust the alloted storage space and stops
  • Makes sure your logs don't exhaust the alloted disk storage
  • Makes sure the external services you depend on don't stop working after certain amount of request are executed.

Security Testing

Security Metrics Warning Categories:

• Warning
• Low
• Medium
• High
• Critical

You can click a warning category of the pie chart to isolate only warnings of that kind in the other sections.

The Security Vulnerabilities section will display a breakdown of the quantity of each vulnerability your project has by title.

The Location of Vulnerabilities section will show the type of vulnerability along with the file location of the vulnerability inside of your project.

Contributors

Daniel Sin 🖇️ 🐙

Trang Do 🖇️ 🐙

Paul Krapivin 🖇️ 🐙

Wan Ting Lee 🖇️ 🐙

Aaron Rivas 🖇️ 🐙

• 🖇️ = LinkedIn
• 🐙 = Github