slicetest weekly downloads statistics

slicetest

Report a bug / 不具合報告 · Contributing / 貢献ガイド

Tests that sit between unit tests and end-to-end tests, for apps written in any language or framework.

slicetest starts your app as a real process, points it at a real Postgres (or MySQL, or SQLite) and at stub servers for the services it calls, and lets you check all three sides in one scenario:

No browser, no mocked database, no hooks inside your app. The app only has to read its port, database URL and outbound base URLs from environment variables. (State the app keeps in memory is the one thing that may need your help: state between scenarios.)

Why, and when not to use it

Testing an API against a real server, a real database and stubbed third parties is an established approach, and most stacks can do it already (Spring Boot starts a real server in tests and integrates with Testcontainers; Playwright has API testing; WireMock stubs HTTP services and simulates faults). slicetest doesn't claim something only it can do. It bundles the parts you'd otherwise assemble per project, for any language the app is written in: starting the app, the database and the stubs, resetting them between scenarios, checking the three boundaries in one scenario, and explaining a failure.

The usual labels mix up three separate questions: is anything mocked, is a real server running, and how much does the test cover. Side by side:

| Approach | Mainly checks | Strong at | Limits |

| Function / class tests | Logic, boundaries, exception branches | Control over internal dependencies | Real connections and SQL need a separate check | | API integration tests you already have | HTTP, the app, a real DB, calls to external services | Fit with your existing framework | Starting, resetting and diagnosing is yours to build, depending on the setup | | slicetest | The same API-level tests, plus environment management and diagnostics | Several checks in one scenario; the same scenarios for any language | Reaching into the app's internals, or a dependency it doesn't support, takes extra design | | Browser E2E | From UI actions through the main flows | What happens in the browser | Poor at controlling fine-grained internal state |

What slicetest keeps real: the HTTP server, the SQL and the migrations. What it replaces: services you don't own, with stubs. With OpenAPI specs it also checks that your stubs' replies could come from the real service, within what the spec documents (what each check does and doesn't guarantee).

Whether it's worth adopting depends on what you have:

| Team or use | Verdict |

| No test setup for the API, the DB and external calls | A small trial fits | | Several languages, and you want one way to test all of them | A comparatively strong candidate | | Failures take long to investigate in logs and the DB | Worth measuring what the combined output saves | | Spring (or similar) integration tests that already run stably | Don't plan to replace them; measure what slicetest would add | | Many branches of internal logic to cover | Unit tests first | | The UI, or a real identity provider or external API | Browser E2E, or a check against the real service, alongside |

Not measured yet: whether it is faster than other setups, cheaper to maintain, or stable over long use on real projects. The one comparison made so far (the same nine checks on a Spring Boot app, written with JUnit + Testcontainers + WireMock and with slicetest; run times, flaky runs, injected faults, and what each failure shows) is in examples/comparison, with its limits: one machine, one small app, both suites by one author. The speeds quoted below are narrow measurements, with their conditions.

The database is reset between scenarios with TRUNCATE ... RESTART IDENTITY CASCADE over every table, and the app keeps its connections, so this works with any driver or ORM. In the spike that chose this (TRUNCATE polls RESTART IDENTITY: one table, no CASCADE, 20 runs, median, a Postgres container on a laptop) the reset took 1.5 ms; dropping and re-creating the database took about 130 ms and crashed some apps when their pooled connections were cut. That is the reset step alone, not the time of a test run, and it wasn't measured with more tables. Since the table list is now read at every reset, a later check on three small tables (same machine, 300 resets) took 1.4 ms for the TRUNCATE alone and 2.0 ms with the list. Of the app's own state, only what is in the database is reset by default: whatever the app keeps in memory or does in the background survives into the next scenario unless you say otherwise (state between scenarios).

Quick start…

Description from the npm listing.