wosp-io / orca Goto Github PK

a modern performance testing toolkit, using JavaScript

License: Apache License 2.0

JavaScript 100.00%

orca's Introduction

A Node.js library to 'orca'-strate automated performance testing with a single API. Orca is a modern tool built for all aspects of performance testing, giving teams the ability to test all layers of the application stack. Conduct simple load tests, run end-to-end performance tests, audit page load times, gather resource bundle metrics, and more.

Install: npm i @wosp-io/orca

Simplest Working Browser Example

const { Browser } = require("../src/browser.js");

(async () => {
  await Browser.launch({ headless: true });
  await Browser.newPage();
  await Browser._page.goto("http://wosp.io");
  Browser.kill();
})();

Simplest Working HTTP Example

const { Http } = require("../src/http.js");

(async () => {
  Http.options({
    vus: 5,
    duration: 30,
    ips: 2,
  });
  Http.requests([
    {
      url: "http://httpbin.org/get",
      method: "GET",
    },
  ]);
  await Http.send();
})();

HTTP Load Test Report

orca's People

Contributors

Stargazers

Watchers

orca's Issues

Feature: Simplest API Over Playwright

Design and develop a basic API over the playwright package. The ability to spin up a browser and get reference to it and its pages are going to be a necessary feature. Keep in mind we eventually want to be able to hook into lighthouse via a port.

The following functionality should be available before this ticket/issue can be closed:

Start a playwright browser session
Store reference to that browser session
Create new page
Store reference to that page

Feature: Network Defaults to Dense Desktop 4G

In order to create the most realistic simulation when running lighthouse reports, the tool should have the network default to DenseDektop4G as it is currently the closest we can get to the traditional no throttling seen in Lighthouse versions 2.0.0-3.0.0. we would ideally like to get as close to what users will see during regular desktop/laptop use while running these reports (and we'll assume our users will as well).

This ticket/issue is considered complete when:

The DenseDesktop4G configuration is added
There is logic making it the default

Note: The logic setting this as default should be flexible enough to allow for the ability to add other network configurations in the future.

Feature: Component/Element Timings Based on Browser Load Events

It is difficult to capture load timings of elements and larger components without doing some manual work or potentially adding some profiling apis or timing logic to an applications codebase. With this I would like to introduce a feature that allows us to capture visible element load timings based around three specific browser load events (load, domcontentloaded, and networkidel0).

This ticket/issue is considered complete when the following things have been implemented:

The ability to capture the above load timings of a specified element on the current page.
A test has been added to browser-test to make sure it functions correctly.

Feature: Implement throughput rating via function and options configuration

load testing requires a good deal of control over the requests being sent out by the given tool or code. One of the most elementary functionalities is being able to set a throughput rate in order to throttle the amount of requests being sent out during a given time span. For now (the first implementation of this functionality anyway), we would like to specify the rate and time period as requests per second.

The ticket/issue will be considered complete after the following logic has been implemented:

Throughput rate can be set in the form of requests per second
A test ensuring the following throughput logic is correct is added to http-test

Feature: Step/Group Timing Wrappers

The ability to capture timings of individual steps throughout a given end-to-end test is going to be an integral part of this tool. Creating the a wrapper for puppeteer logic to gather metrics will be the main purpose of this issue.

To close this issue the following must be accomplished:

Wrap puppeteer logic to capture the timing of a specific set of tasks/actions
Capture the total time of all steps
include a test for this within the browser-test.js script

Feature: Store http request results in a data structure

This ticket should be relatively simple, store the results in a data structure and set it as the value for this._http_results.

This ticket is considered complete when:

The logic for storing the http results has been implemented
A test for this has been added to http-test

CI Pipeline: Add Prettier Check Step

For this project we intend to use prettier as our linter. Keeping code formatted correctly on projects is important, so we should standardize this via our actions and workflows.

This ticket is considered complete when:

There has been a prettier check step added to our workflow.yml
Successfully fails the build if files are formatted incorrectly

Feature: Simplest API Over Lighthouse

Design and develop a basic API over the lighthouse package. The ability to spin up a lighthouse instance, spin up a playwright browser instance, and connect the two via a browser port is going to be a necessary feature. Running a lighthouse audit and capturing page load metric timings and scores will also be a key feature needed.

The following functionality should be available before this ticket/issue can be closed:

Start a lighthouse instance, store and be able to reference it
Connect to a playwright instance
run a lighthouse audit
Capture and store/return lighthouse report metrics (score and timing)

Feature: Parallel http requests (batches?)

The overall goal of this ticket is to have logic that allows for http requests to be defined and then executed in parallel. Ideally this would allow for batch requests in addition to singular http requests. Perhaps, we separate these into separate functions under the http class.

This ticket will be considered complete when:

Basic request functionality is completely implemented
Basic batch request functionality is completely implemented
Tests for both are added to a new http-test file

Feature: Resource/Bundle Sizes & Timings

As part of running a lighthouse audit, or as a separate function, develop the ability to capture timings and sizes of all resource urls (ending in .js and .css). This is another necessary aspect of the tool. It allows user to see what resources are slowing down the page load timings of their application.

This ticket is complete when:

Capturing resource sizes and timings is added as part of an audit.
Stored as this._resource_timings_and_sizes.
A test is added to browser-test to make sure everything functions correctly.