JSVerify

JSVerify is a free, open-source property-based testing library for JavaScript and TypeScript. It is best for developers who want generated inputs and shrinking without committing to a particular test runner. It is a strong fit for broad input spaces, but TypeScript DSL restrictions and unstable utility APIs may rule it out for some projects.

Overview

JSVerify checks properties that should remain true across many generated inputs instead of depending only on hand-written examples. That makes it useful for functions whose edge cases are difficult to enumerate, such as parsers, data transformations, and validation logic. It complements example-based tests rather than replacing them, and its finite runs should be treated as broad sampling, not exhaustive proof.

The library is installed with npm install jsverify and is maintained by phadej. Its GitHub project uses the MIT license, making it suitable for open-source and commercial codebases without a paid plan.

Key features

• Generated property checks: The documented default performs 100 tests with a maximum generated-value size of 50. The check API lets you change the test count and size, so teams can choose quicker feedback or wider exploration. Those defaults are practical for routine checks, but they do not establish certainty over every possible input.
• Counterexample shrinking: When a property fails, JSVerify attempts to reduce the generated input to a smaller failing case. A compact counterexample usually makes debugging faster, although the process does not guarantee the absolute smallest input.
• Asynchronous properties: Properties may return Promises, allowing asynchronous methods to be checked in the same property-based style as synchronous functions. This is valuable for code that performs async operations, provided the surrounding test setup handles returned promises correctly.
• Framework agnostic: JSVerify can run with Mocha, nodeunit, Jasmine, or another framework. That avoids forcing a runner migration, though the library does not provide a single integrated runner experience of its own.
• Reproducible failures: Generated values are deterministic when primitives from the random module are used, and users can set an RNG state. Replaying a failing sequence is therefore realistic when generation follows those rules; other randomness can reduce repeatability.
• Configurable checks: Options cover test count, maximum generated size, quiet output, and random-generator state. This gives CI and local runs different tuning choices without changing the property itself.
• TypeScript support with a boundary: TypeScript typings are provided, but TypeScript specs cannot use the type DSL. Teams relying heavily on that DSL should expect to design around the limitation rather than assume feature parity with JavaScript.
• No stateful testing: JSVerify is aimed at generated values and properties, not stateful-model testing. Projects needing dedicated state-machine coverage will need another tool or an additional testing layer.

Pricing

JSVerify costs free under its single free plan. It is an open-source library with no paid tier, seat charge, quota, trial, or renewal term described. That makes it an uncomplicated choice for individual developers and teams that can adopt a library directly; there is no commercial support or expanded plan to move to when requirements grow.

Platforms

JSVerify is listed for self-hosted and web use, with JavaScript and TypeScript support. Self-hosting suits projects that want tests to run inside their existing development or CI environment, while web classification reflects its browser-facing ecosystem rather than a hosted testing service.

Who it's for

Choose JSVerify when your JavaScript code has large or irregular input spaces and your team already uses a compatible test framework. It is particularly well suited to developers who value smaller failure cases and deterministic replay without paying for infrastructure. It is less suitable when TypeScript specs must use the type DSL, when stateful testing is central, or when production code depends on utility functions whose compatibility may change even in patch releases. The README describes those utilities as contribution-oriented and warns that they can change incompatibly, so stable public APIs should be preferred for long-lived projects.

Pros and cons

Pros

• Free MIT-licensed library: There is no licensing bill or plan administration, and the license fits commercial use.
• Useful failure reduction: Shrinking can turn a complex generated failure into a more actionable case.
• Runner flexibility: Mocha, nodeunit, Jasmine, and other frameworks can host the checks.
• Replay controls: RNG-state configuration and deterministic primitives help reproduce failures.
• Promise-aware properties: Asynchronous methods can be covered without abandoning the property-based approach.

Cons

• TypeScript DSL limitation: TypeScript specs cannot use the type DSL, which can constrain typed test suites.
• No stateful testing: Stateful workflows require another solution.
• Utility API risk: Exposed utility functions may change incompatibly in patch releases.
• Finite exploration: The 100-test default and size cap provide sampling, not exhaustive verification.

Alternatives

For a wider category comparison, see Property-Based Testing Tools.

• fast-check is the better shortlist choice if you want another MIT-licensed JavaScript/TypeScript property-testing project with web and API availability.
• ScalaCheck fits teams working in Scala across Linux, macOS, or Windows.
• Racket QuickCheck suits Racket users who can run Racket 6.0 or newer.
• FsCheck is intended for .NET developers using its BSD-licensed NuGet packages.
• Gopter is a Go-oriented MIT-licensed option for Linux or self-hosted environments.
• Scala Hedgehog is another free open-source Scala testing library for Linux.
• PropCheck targets Ruby projects on Linux or self-hosted systems and requires Ruby 2.5.1 or newer.
• QCheck is a free BSD-2-Clause choice for OCaml property-based testing on Linux.

Verdict

JSVerify is a sensible pick for JavaScript teams that want generated-input testing, shrinking, asynchronous properties, and reproducible failures in a free, runner-agnostic package. Choose it when those capabilities matter more than stateful coverage or unrestricted TypeScript DSL use. Look elsewhere if those limitations, or the warning about changing utility functions, conflict with your project’s stability and typing requirements.