ZerocodeTDD describes API and Kafka tests as JSON, not as JUnit code

A test scenario is a data file with a verify block

ZerocodeTDD is described as a no-code low-code automated testing tool for data streams such as Kafka, microservices APIs and databases, using JSON. The framework is Java, published to Maven Central under the artifact org.jsmart:zerocode-tdd, and the working unit of a test is a scenario file rather than a test class.

The shape of a scenario is what makes the tool approachable. A request block carries the url, the method and the request headers, a retry block declares max attempts and a delay in milliseconds, and a verify block declares the expected status, headers and body. The README gives the same scenario twice, once in JSON and once in YAML, and the two are equivalent.

{
  "url": "api/v1/customers/123",
  "method": "GET",
  "request": {
    "headers": {
      "Content-Type": "application/json"
    }
  },
  "retry": {
    "max": 3,
    "delay": 1000
  },
  "verify": {
    "status": 200,
    "headers": {
      "Content-Type" : [ "application/json; charset=utf-8" ]
    },
    "body": {
      "id": 123,
      "type": "Premium Visa"
    }    
  },
  "verifyMode": "LENIENT"
}

Note what is absent. There is no setup, no teardown, no fixture builder and no assertion API. The expected body is written in the same shape as the request body, so a test author copies the payload the service is supposed to return and edits the values that differ. The README calls this out as the point of the design: the payload and headers structure can be used for validation as it is, without manipulation, or a flat JSON path can be used to skip the whole object hierarchy.

verifyMode LENIENT is the switch between exact and partial matching

The verifyMode field in the scenario above is worth spending time on, because it is the difference between a brittle test and a useful one. The scenario sets it to LENIENT, and the README separately documents the distinction between Validators and Matchers, pointing readers to its own assertions documentation for that comparison.

What the field does is control how much of the declared body has to match. A strict comparison against the whole body means any extra field in the response fails the test, which is correct when the contract is exactly what you wrote down and wrong the moment the service adds a field. A flat JSON path check targets one location in the response and ignores the rest, which is what you want when the surrounding payload is large and not the point of the test.

The tension between the two is inherent to the design, and it is the main thing to settle when a team adopts this tool. The library can express both, so the question is a convention question rather than a capability question: when does a team write a whole body and when does it write a path? The README does not set that convention, so it has to be decided locally, and enforced, otherwise the suite becomes a mixture of two different strictness levels with no obvious rule.

The same observation applies to the retry block. The example declares max 3 and delay 1000, which is a straightforward way to say retry a failing call three times with a second between attempts. That is a different tool from the one people reach for when they want to assert eventual consistency, since a retry that hides a real failure makes the test report success on a broken service.

The scenario file has a published JSON Schema, and an AI prompt points at it

ZerocodeTDD publishes a JSON Schema, Draft-07, for scenario files at schema/zerocode-scenario-schema.json inside the repository, and points to it from robots.txt at the project root. The README explains why: it is there so that if you are developing custom tools around the framework, you can validate that what you generate conforms to the schema the framework itself expects.

This is the design choice that makes the project usable outside the Java ecosystem, and it is bigger than it first looks. A scenario file is a self-describing document with a published contract, so an editor can validate it, a linter can check it, and a generator can be checked against it. The README goes further and gives a ready made prompt to hand to Claude Code, CoPilot, Codex or similar tools: write a Zerocode scenario that conforms to schema/zerocode-scenario-schema.json for your API or Kafka or database test idea, using the assertions block rather than verify, and including retry of 3 attempts with 500ms delay.

That last detail is a real inconsistency in the documented surface. The generated-scenario prompt asks for the assertions block, while every worked example in the README uses verify. The framework documentation apparently supports both names, or the prompt is out of step with the examples, and the README does not reconcile the two. Anyone using the prompt as given should check the resulting file against the schema, and should expect to try one keyword and fall back to the other.

Running a scenario from the command line with Steply

The quick start in the README does not go through Maven. It points at Steply, described as a CLI only tool, and gives one command for running a scenario against a target environment.

steply --scenario tests/validate_github_user.json --target-env env/sit.properties

Two things are being expressed on that line. The scenario is a path to a JSON file, and the target environment is a properties file, which means the endpoint, credentials and other environment specific values are kept out of the scenario. That separation is the practical argument for a file-driven test format: the same scenario can run against a local service, a SIT environment and production, and the only thing that changes is the properties file passed in.

For teams that prefer Maven, the library is published on Maven Central under org.jsmart:zerocode-tdd, and the README links the release list on search.maven.org. The version history is worth noting because the coordinates changed. The current artifact is zerocode-tdd, and the README keeps a separate badge row for older releases under the name zerocode-rest-bdd. A build file written against org.jsmart:zerocode-rest-bdd is referring to the old naming, and migrating a project means changing the coordinates, not just the version.

The repository layout explains the breadth of what is supported. There are example directories for HTTP, Kafka and JUnit 5 testing, a core/ directory holding the library, a docker/ directory, a schema/ directory, a zerocode-maven-archetype/ directory for generating project skeletons, and a pom.xml at the root. Supporting files such as BUILDING.md, CI.md, COMPARISONS.md, RELEASE.md and CODE_OF_CONDUCT.md sit alongside them.

Kafka, SOAP, databases and load scenarios sit on the same file format

The topic tags on the repository list api, assertions, automation, data pipeline, dsl, etl testing, framework, java, json, kafka, library, low code, nocode, soap and testing, and the README backs that up with badges for API automation, performance testing and Kafka testing, each pointing at its own documentation page.

The same scenario schema covers the transports. The README describes the framework as covering REST, SOAP, Kafka real time data streams and much more, and the project description names data pipelines, ETL, REST API, Kafka, databases and load scenarios as the target areas, with everything defined in simple JSON or YAML. A SOAP example is even given as a method invocation with XML input, linked from the README itself.

The interesting part is the consequence of one format spanning all of them. A test for a Kafka consumer and a test for a REST endpoint assert in the same vocabulary, so a tester's mental model transfers across the stack instead of resetting at each transport. For a data pipeline that spans an API, a topic and a database, that means the whole flow can be expressed in files that the same person can read.

The claims about load and performance deserve a separate note on what is actually documented. The README links a page titled Load or Performance Testing with an IDE based marker, and the project description lists load scenarios among the supported types. What the README does not do is document the load model itself, the concurrency controls, or the reporting format, so a team evaluating this for performance work is relying on the linked documentation page rather than on what the repository itself shows.

What a JSON assertion model cannot express

The trade-off is the same one every declarative test format makes, and it is worth naming before a team discovers it in a code review.

A JSON path assertion is a string. If the check you need is a relationship between two fields, a numeric comparison with a tolerance, a regex over a substring, or a condition on the number of items in a list, you are pushing that logic into whatever the framework's assertion vocabulary supports or you are leaving the test out. The README points to a page explaining Validators versus Matchers, which suggests a reasonably expressive vocabulary exists, and the verify block demonstrates nested object matching and header matching with a list of accepted values. But the documentation does not enumerate the full set of assertion operators, and the schema is the only machine readable contract published for scenario files.

The second limit is test independence. Because a scenario is a self-contained document with no setup phase, any state a test needs has to come from the environment properties file, or from another scenario that ran first and left the service in the right state. The README does not document ordering, fixtures or a data setup step, so a suite that needs a created customer before a GET of that customer has to solve that outside the framework. This is the usual cost of a low-code format and it is a real design constraint, not a missing feature in a buggy sense.

The third limit is debugging. When a JSON assertion fails, the error message points into a file rather than into a line of test code, and the framework's own documentation is where you would look for the failure output format. The documentation site is indexed and claims to find results instantly, which suggests the reporting is designed around search rather than around a stack trace.

Apache-2.0 licensing and a fast release cadence

The project is released under Apache 2.0, with a LICENSE file at the top of the repository and a link to the license text in the README. The artifact is published to Maven Central under org.jsmart:zerocode-tdd, and the README points to the release listing on search.maven.org. Apache-2.0 requires keeping the copyright notice and the licence text, and the ASF-style governance files are not present because this is not an Apache Software Foundation project, though it does follow a similar community pattern with a CODE_OF_CONDUCT.md, CONTRIBUTING.md and a Slack workspace.

Release cadence is a genuine strength here. The tagged versions are 1.4.2 on 2026-05-20, 1.4.3 on 2026-05-26 and 1.4.4 on 2026-08-31, and the last push to the master branch was on 2026-09-22. That is a project shipping patches within days of each other rather than every few years, which matters for a testing library because it is exactly the kind of tool whose dependencies move underneath it.

The documentation is hosted separately from the code, at zerocode-tdd.tddfy.com, and the README notes that anyone can amend or improve it, with the steps and guidelines for that in the project wiki. The wiki also carries the developer guide and the page listing the smart projects using Zerocode, which names Vocalink, HSBC, HomeOffice and others as users of the tool for production drop of microservices and data pipelines. The wiki also explains the schema validation workflow, which is the piece most relevant to anyone building tooling on top of the scenario format.

Editorial conclusion

ZerocodeTDD fits a team whose testers and developers both need to author service and data pipeline tests without owning a Java test class, and whose CI can run a JSON scenario file through Maven or the Steply CLI. It does not fit a project that needs type-safe assertions, custom assertion logic in code, or a test framework that plugs into an existing JUnit extension model, because the scenario is the source of truth and the assertions are strings. Before adopting it, check that your assertion vocabulary covers the checks you actually need, since the verify block supports both whole payload matching and flat JSON path checks, and remember that the published package name changed from org.jsmart:zerocode-rest-bdd to org.jsmart:zerocode-tdd, so older build files reference an artifact that is no longer where the new releases live.

Frequently asked questions

Official sources

1. authorjapps/zerocode on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases