Introduction

Stoobly is an API mock framework with seamless CI setup that enables end-to-end (E2E) testing.

Why use Stoobly?

⚡ Easily create realistic API mocks by recording HTTP(S) requests.

💡 Maintaining mocks gets expensive. Streamline maintenance with stale mock detection and automated regeneration.

🔨 Minimize regressions of customer workflows with fast and reliable E2E tests.

🚀 Supercharge CI setup with ready-to-go tooling. Reduce CI setup time from two weeks to one day.

Why do E2E Testing?

Stoobly enables E2E testing. But before we talk about how, let us first answer what benefits E2E testing provides when compared to other forms of testing:

✅ Validates Real-World Scenarios

✅ Detects Integration Issues

✅ Provides High Code-Coverage

While full of benefits, E2E testing has several drawbacks:

Dependence on live services make them flaky and slow
Requires significant tooling support (test runner, mock framework, and CI setup)

Stoobly Enables E2E Testing

The goal of E2E testing is to ensure that real-world scenarios behave as expected. In order to achieve this goal, E2E tests have to be fast, reliable, and running as part of CI.

API Mock Framework

Leverage a complete solution for API mocking.

By serving as an API mock framework, Stoobly makes testing fast and reliable. Stoobly provides the following solutions to problems universal to mocking:

Problem

Solution

Creating

Manual and recording

Stale Detection

Contract testing

Updating

Manual and automated mock regeneration

Grouping

Scenarios

Response Matching

Pattern and contract based configurations

Sharing

Git commitable mock storage format

Out-of-the-Box CI Setup

Drastically reduce CI setup time. Minimize maintenance.

Stoobly also empowers users to scaffold tooling to overcome the barrier between running E2E tests locally and running them in CI. Stoobly provides the following solutions to problems universal to CI setup:

Problem

Solution

Separate mocks that belong to different services

Service definitions

Separate development, testing and CI configurations

Workflow definitions

Creating configurations

Generated Docker compose files

Updating configurations

Minimal parameters and centralized resource definitions

Ready to get Started?

Looking to Learn More?

NextUse Cases

Last updated 5 months ago

Was this helpful?

Introduction

Stoobly is an API mock framework with seamless CI setup that enables end-to-end (E2E) testing.

Why use Stoobly?

⚡ Easily create realistic API mocks by recording HTTP(S) requests.

💡 Maintaining mocks gets expensive. Streamline maintenance with stale mock detection and automated regeneration.

🔨 Minimize regressions of customer workflows with fast and reliable E2E tests.

🚀 Supercharge CI setup with ready-to-go tooling. Reduce CI setup time from two weeks to one day.

Why do E2E Testing?

Stoobly enables E2E testing. But before we talk about how, let us first answer what benefits E2E testing provides when compared to other forms of testing:

✅ Validates Real-World Scenarios

✅ Detects Integration Issues

✅ Provides High Code-Coverage

While full of benefits, E2E testing has several drawbacks:

Dependence on live services make them flaky and slow
Requires significant tooling support (test runner, mock framework, and CI setup)

Stoobly Enables E2E Testing

The goal of E2E testing is to ensure that real-world scenarios behave as expected. In order to achieve this goal, E2E tests have to be fast, reliable, and running as part of CI.

API Mock Framework

Leverage a complete solution for API mocking.

By serving as an API mock framework, Stoobly makes testing fast and reliable. Stoobly provides the following solutions to problems universal to mocking:

Problem

Solution

Creating

Manual and recording

Stale Detection

Contract testing

Updating

Manual and automated mock regeneration

Grouping

Scenarios

Response Matching

Pattern and contract based configurations

Sharing

Git commitable mock storage format

Out-of-the-Box CI Setup

Drastically reduce CI setup time. Minimize maintenance.

Problem

Solution

Separate mocks that belong to different services

Service definitions

Separate development, testing and CI configurations

Workflow definitions

Creating configurations

Generated Docker compose files

Updating configurations

Minimal parameters and centralized resource definitions

Ready to get Started?

Installing the Agent

Looking to Learn More?

NextUse Cases

Last updated 5 months ago

Was this helpful?