# EvoMaster evolves API test cases from a schema instead of guessing them

> EvoMaster is an open source, AI driven fuzzer for REST, GraphQL and RPC APIs that evolves a population of generated test cases to maximize coverage and fault detection, then emits them as executable suites. It is built for teams that want generated regression tests and security findings without an external service dependency, and its whitebox mode is limited to JVM targets.

**WebFuzzing/EvoMaster** — The first open-source AI-driven tool for automatically generating system-level test cases (also known as fuzzing) for web/enterprise applications. Currently targeting whitebox and blackbox testing of Web APIs, like REST, GraphQL and RPC (e.g., gRPC and Thrift).

- Repository: https://github.com/WebFuzzing/EvoMaster
- Stars: 795 · Forks: 120
- Language: Kotlin
- License: LGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/webfuzzing-evomaster

## Generating test cases for web and enterprise APIs

EvoMaster describes itself as the first open source AI driven tool that automatically generates system level test cases for web and enterprise applications, and it traces that claim to 2016. The scope is deliberately narrow and useful: APIs. REST, GraphQL and RPC, with gRPC and Thrift named as the RPC targets. The output is not a stream of crash input. Alongside inputs that find program crashes, the tool generates small effective test suites in Python, JavaScript and Java or Kotlin JUnit format, which are meant to be kept and run as regression tests. That second capability is the one most teams will actually use, and it separates the project from a fuzzer whose output dies with the run. The documentation also claims that more than 30 different kinds of faults can be found automatically, ranging from HTTP semantics checks to security vulnerabilities such as BOLA and SQLi, with the fault catalogue living in docs/faults.md. The audience is therefore API owners and testers who want machine-generated inputs and a checked-in test suite from one run.

## An evolutionary algorithm drives the search, not random luck

The mechanism is search based rather than blind. EvoMaster internally uses an evolutionary algorithm together with dynamic program analysis, and the documented approach is to evolve test cases from an initial population of random ones, trying to maximize measures such as code coverage and fault detection. Additional AI heuristics improve performance further, and the project places this line of work in the field of search based software testing. The practical consequence is that a run is directed by feedback. Test cases that reach new code or trigger new fault types survive and produce offspring, and the ones that go nowhere do not. That also explains the runtime options. A run needs a time budget and a request rate, because the tool is driving real traffic at your service, and the Docker examples show a run bounded by --maxTime 10s with a --ratePerMinute 60 cap. Without whitebox feedback the same search still runs, but the measurements guiding it are weaker, which is why the documentation says blackbox results will be worse than whitebox results, for example due to the lack of code analysis.

## Whitebox mode means bytecode, so it means JVM

The two testing modes are not equally capable and the boundary is explicit. Blackbox mode runs on any API regardless of its programming language, for example Python and Go, and the default test case output is Python with other formats available. Whitebox mode is described as usable for APIs compiled to the JVM, such as Java and Kotlin, where EvoMaster analyses the bytecode of the tested application and applies heuristics such as testability transformations and taint analysis to generate more effective cases. The supported range is JDK 8 and the major LTS versions after that, currently JDK 21, and the documentation is blunt about the rest: it might work on other JVM versions, but there is no support for them. That restriction propagates further. The documentation notes there was initial support for other languages as well, and the tree carries an outdated/ directory alongside core/, core-extra/, core-tests/, client-java/, test-utils/ and a pypi-distribution/ directory. For a team whose service is written in Go or Python, blackbox mode is the ceiling, and the coverage you get depends entirely on the service's own instrumentation.

## Installing through pip and running the first fuzzing session

Since version 6.0.0 the recommended install path is PyPI:

```bash
pip install evomaster
```

The tool then runs from the command line against a schema:

```bash
evomaster --schema https://petstore.swagger.io/v2/swagger.json
```

Against the PetClinic example API from Swagger, that run fuzzes for 60 seconds. Updating is a separate invocation, pip install --upgrade evomaster, and the documentation notes that some Mac users reported the upgrade not picking up the latest version, in which case python3 -m pip install --upgrade evomaster is the fallback. The Docker route is offered as well, mounting a directory so the generated files land on the host:

```bash
docker run -v "$(pwd)/generated_tests":/generated_tests webfuzzing/evomaster  --schema  https://petstore.swagger.io/v2/swagger.json
```

The volume syntax is shell dependent, and the documentation spells out the variants. A Git Bash shell on Windows needs a leading slash before the dollar sign, and a Command Prompt terminal needs the percent sign CD percent form:

```bash
docker run -v %CD%/generated_tests:/generated_tests webfuzzing/evomaster  --schema  https://petstore.swagger.io/v2/swagger.json
```

PowerShell uses the brace form. If a run fails, the troubleshooting notes are short: Docker must be installed and running, you need the rights to mount the volume, and the Docker documentation has the per shell syntax requirements.

## What lands in generated_tests and what the report shows

After a run, the generated files are inspected under the generated_tests folder, and since version 4.0.0 the tool also creates an interactive web report by default. The report comes with an overview and an endpoint breakdown, so a run produces two distinct artefacts: the test files you can commit, and a view of what the tool managed to reach. The Docker image itself makes the memory story explicit. It is built on amazoncorretto:21-alpine-jdk, copies a built core/target/evomaster.jar into the image, and starts it with a MaxRAMPercentage of 75.0 and a --runningInDocker true argument. The comment in the Dockerfile notes that the default 25 percent is too limited for an image running just a Java program, and that overriding with -Xmx would ignore the constraints set on the image and could lead to crashes. For a long fuzzing session on a shared CI runner, that setting is the difference between a stable run and an out of memory failure.

## No telemetry, no external calls, and a licence to check

Two operational properties are worth taking at face value and verifying in your own environment. The first is that the tool does not use telemetry and does not require a connection to any external service on the internet besides the tested application, so it can be run in house without leaking an IP to external parties. The second is that there is no monetary cost involved and no need for paid external services such as external LLM APIs, with funding coming from public research. Both claims matter because the alternative approach, sending your API schema and traffic to a hosted fuzzing service, is often what a security review will object to. The licence is LGPL-3.0, which is a consideration rather than an obstacle for a tool used internally. The repository also carries release_notes.md at the top level, and the release history shows v6.2.0 on 2026-09-15, v6.1.1 on 2026-07-08 and v6.0.0 on 2026-05-20, with the last push on 2026-10-19. Release notes at the root are where to look before upgrading, since a major version jump in a fuzzer changes the command line options.

## Where this differs from hand written API test suites

The alternative most teams already have is a maintained collection of API test cases, written by hand or generated once from a schema and then curated. The difference in approach is direction of effort. A curated suite encodes what the API is supposed to do, so it is precise about expected behaviour and stable across runs, but it only covers the cases somebody thought of, and it needs a human every time the API changes. EvoMaster inverts that. It starts from the schema, explores far more of the surface than a human would enumerate, and reports faults in terms of HTTP semantics and common API vulnerability classes rather than in terms of your intended behaviour. The two are complements rather than substitutes, and the documentation points at the intended use by generating small suites specifically for regression testing. What you give up by relying on generation alone is the specification of correct behaviour, since an automatically produced test suite says little about what the service should return. What you give up by staying fully manual is coverage of the edge cases your users will find.

## Conclusion

Adopt EvoMaster when your API is described by a schema and you want both a generated regression suite and a list of API level faults such as BOLA or SQL injection, and when you can run the tool in house with no telemetry and no paid service calls. Do not adopt it as a general purpose fuzzer for native binaries or non JVM code coverage, since whitebox analysis is limited to JVM applications. Verify first that your API exposes a schema the tool can read, that the output format you want is one of the supported ones, and that a blackbox run produces usable results for your service before you rely on whitebox mode.

## FAQ

### How do I install and run EvoMaster for the first time?

Since version 6.0.0 the recommended install is pip install evomaster, and you run it against a schema with a command such as evomaster --schema https://petstore.swagger.io/v2/swagger.json, which fuzzes the PetClinic example API for 60 seconds. A Docker image is also provided.

### Does EvoMaster need an external service or send my data anywhere?

The documentation states that there is currently no telemetry, that it does not require a connection to any external service besides the tested application, and that it can be run in house without leaking an IP to external parties. It also says no paid external services such as external LLM APIs are needed.

### Which programming languages can EvoMaster test in whitebox mode?

Whitebox mode is for APIs compiled to the JVM, such as Java and Kotlin, where the tool analyses the bytecode, and the supported range is JDK 8 and the major LTS versions after that, currently JDK 21, with no support for other JVM versions. Blackbox mode works on any API regardless of its language.

### What output formats does EvoMaster produce?

It generates small effective test suites in Python, JavaScript and Java or Kotlin JUnit format, with Python as the default in blackbox mode and other formats available. Since version 4.0.0 it also creates an interactive web report by default, and the generated files are written under the generated_tests folder.

### What kinds of faults can EvoMaster find automatically?

The documentation states that more than 30 different kinds of faults can be found automatically, ranging from HTTP semantics checks to security vulnerabilities such as BOLA and SQLi, and it points to the fault catalogue in docs/faults.md for the details.

## Sources

- [Issues](https://github.com/WebFuzzing/EvoMaster/issues)
- [License: LGPL-3.0](https://github.com/WebFuzzing/EvoMaster/blob/master/LICENSE)
- [README](https://github.com/WebFuzzing/EvoMaster/blob/master/README.md)
- [Releases](https://github.com/WebFuzzing/EvoMaster/releases)
- [WebFuzzing/EvoMaster on GitHub](https://github.com/WebFuzzing/EvoMaster)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/webfuzzing-evomaster