DEV Community: Luis Iñesta Gelabert

Azertio: API and Database Testing Without the Glue Code

Luis Iñesta Gelabert — Sun, 17 May 2026 17:37:07 +0000

If you have ever maintained a Cucumber + RestAssured test suite, you know the feeling. The feature files look clean. But underneath there are dozens of step definition classes, ScenarioContext maps to pass state between steps, @Before hooks to wire up the HTTP client, and a pom.xml that has grown to include JDBC drivers, connection pools, and fixtures loaders just to back up a few database assertions.

The tests work. But they are a project in themselves.

Azertio is a new open-source testing tool that takes a different approach: instead of writing glue code, you declare plugins. Instead of managing a build file, you configure a YAML file. Instead of parsing JUnit XML reports, you browse a live execution history in your IDE.

Let me walk you through what it does and how it is designed.

The Problem: Tests That Require Too Much Code

BDD tools like Cucumber are built around a promise: business stakeholders write the test scenarios, developers implement the steps. In practice this rarely holds. Every new step a tester wants to use requires a developer to:

Write a Java method annotated with @Given, @When, or @Then
Wire it to a Gherkin expression via a regex
Manage shared state between steps
Register configuration in a Spring context or a custom hook

The result is that feature files — the part everyone can read — are tightly coupled to a growing body of Java infrastructure that almost nobody reads. And this infrastructure is per-project: if three teams test REST APIs, each team writes their own iMakeGetRequest and statusCodeIs methods.

Azertio's premise is simple: the most common test steps should already exist as reusable, versioned plugins, and you should not need to write any Java to use them.

How It Works

An Azertio project consists of two things: an azertio.yaml configuration file and your .feature files. That's it — no pom.xml, no step definition classes, no build tool.

# azertio.yaml
testProject:
  organization: Acme Corp
  name: Payment Service Tests
  test-suites:
    - name: smoke
      tag-expression: "smoke"
    - name: regression
      tag-expression: "regression or smoke"

plugins:
  - gherkin
  - rest
  - db with org.postgresql:postgresql-42.7.3

configuration:
  rest:
    baseURL: "{{base-url}}/api"
    timeout: 10000

profiles:
  dev:
    base-url: http://localhost:8080
  staging:
    base-url: https://staging.example.com

Then you install the plugins (downloaded from Maven Central and cached locally):

azertio install

And run your tests:

azertio run -s smoke -p staging

Your feature files can use REST and database steps immediately, with no backing code:

Scenario: Creating a payment persists it in the database
  When I make a POST request to "payments" with body:
    """json
    { "amount": 49.99, "currency": "EUR", "card": "4111111111111111" }
    """
  Then the HTTP status code is equal to 201
  And I store the value of field "id" from the response body into variable paymentId
  * use db "main"
  * db query:
    """sql
    SELECT status FROM payments WHERE id = '${paymentId}'
    """
  * db query count = 1

Variable interpolation (${paymentId}) is first-class. No custom parameter types, no manual string replacement.

Architecture: Plugins All the Way Down

Every capability in Azertio is a plugin — including the Gherkin parser, the REST steps, and the database steps. Plugins are standard Maven artifacts loaded at runtime via the Java Platform Module System (JPMS).

This has concrete consequences:

No classpath pollution. Each plugin runs in its own module layer. A plugin's dependencies cannot interfere with the core runtime or with other plugins. You can have two plugins that depend on different versions of the same library without conflict.

Runtime dependency declaration. Need to test a MySQL database? Add db with com.mysql:mysql-connector-j to azertio.yaml. The JDBC driver is downloaded from Maven Central and loaded into the plugin's module layer at runtime. No pom.xml edit required, because there is no pom.xml.

True extensibility. Writing a custom step plugin is straightforward: implement StepProvider, annotate methods with @StepExpression, and publish the artifact to any Maven repository. Teams that consume it just add one line to azertio.yaml.

@Extension(name = "My Protocol", scope = Scope.TRANSIENT)
public class MyStepProvider implements StepProvider {

    @StepExpression(value = "my.connect", args = {"host:text", "port:integer"})
    public void connect(String host, int port) {
        // your implementation
    }
}

The consuming project gets it automatically on the next azertio install — no code changes, no dependency management.

Benchmark Mode: Performance Testing Without a Separate Tool

One problem with specialized testing tools is proliferation. You have one tool for functional tests (Cucumber), one for performance (Gatling or k6), and you end up maintaining the same test logic in two places.

Azertio has a built-in benchmark mode that works on any compatible step in the same .feature file:

Scenario: Functional — retrieve payment
  When I make a GET request to "payments/1"
  Then the HTTP status code is equal to 200

Scenario: Performance — retrieve payment meets SLA
  Given benchmark mode is enabled with 500 executions and 16 threads
  When I make a GET request to "payments/1"
  Then the benchmark P95 response time (ms) is less than 150
  Then the benchmark error rate is equal to 0.0
  Then the benchmark throughput (req/s) is greater than 200.0

Benchmark runs use virtual threads for high concurrency with low resource overhead. Statistics (min, max, mean, P50, P95, P99, throughput, error rate) are stored with the execution and visible in the VS Code extension alongside functional results. If the P95 threshold is breached, the CI build fails — no Gatling server, no separate pipeline stage.

The Definition / Implementation Model

One of Azertio's most distinctive features is a two-level scenario model that has no direct equivalent in other tools.

In most BDD projects, feature files serve two masters at once: business stakeholders who need to validate that tests reflect real requirements, and engineers who need steps precise enough to execute. These two needs pull in opposite directions, and the result is usually a compromise that satisfies neither.

Azertio solves this with a formal separation. A definition feature (tagged @definition) contains the abstract, business-readable test intent:

@definition
Feature: User Registration

@ID-REG-01
Scenario: A new user can register with valid data
  Given a valid registration form
  When the form is submitted
  Then the account is created
  And a welcome email is sent

An implementation feature (tagged @implementation) contains the concrete, executable steps, matched to the definition by identifier:

@implementation
Feature: User Registration — REST

# gherkin.step-map: 1-1-1-1
@ID-REG-01
Scenario: A new user can register with valid data
  When I make a POST request to "users" with body:
    """json
    { "name": "Alice", "email": "alice@example.com" }
    """
  Then the HTTP status code is equal to 201
  And the response body contains:
    """json
    { "email": "alice@example.com" }
    """
  And the response body field "welcomeEmailSent" is equal to "true"

At plan-build time the two files are merged. The result tree shows the definition structure — business-readable, approvable in a pull request — while executing the implementation steps underneath each abstract step. Stakeholders see the definition; the framework runs the implementation.

The gherkin.step-map comment controls how many implementation steps correspond to each abstract definition step, including 0 for steps that should appear in the result tree but not execute.

This model is particularly useful for:

Regulatory traceability — the definition is the signed-off specification; the implementation is the audit trail.
Multilingual teams — definition in the business language, implementation in the team's preferred language.
Protocol evolution — one definition, multiple implementations (REST today, gRPC tomorrow).

Execution History and VS Code Integration

A persistent frustration with most testing tools is that execution history vanishes. JUnit XML reports go into target/, CI artifacts expire after 30 days, and there is no way to compare last Thursday's run with today's without a separate Allure or ReportPortal setup.

Azertio has a built-in persistence layer with three modes:

Mode	Backend	Use case
`transient`	Temp HSQLDB (deleted on exit)	CI pipelines that only need pass/fail
`file`	HSQLDB file in `.azertio/`	Developer workstation
`remote`	PostgreSQL + MinIO	Shared team history

In remote mode, every CI run writes the full execution tree — plan, suites, scenarios, steps, timings, and binary attachments — to a shared PostgreSQL database. Every developer's VS Code extension connects to the same backend and can browse, inspect, and re-run any past execution from any branch or CI run.

The VS Code extension connects to the CLI via a JSON-RPC server and provides:

Execution history with date, duration, and pass/fail status
Result tree navigation from suite down to individual steps with timings
Attachment inspection — response bodies, CSV query results, any data produced by steps
One-click re-run of any past execution against its original plan and profile
Inline benchmark statistics alongside functional results

No Allure server. No external dashboard. No configuration beyond the persistence block in azertio.yaml.

Comparison: How Azertio Fits Against Other Tools

vs. Cucumber + RestAssured

Cucumber requires glue code for every step — a Java method annotated with @Given/@When/@Then. RestAssured provides the HTTP layer, but state management between steps, configuration wiring, and especially database assertions are all your problem.

Azertio eliminates glue code entirely. The rest and db plugins cover the majority of API and database testing scenarios without writing any Java. When you do need custom steps, you write a plugin once and reuse it across all projects.

The tradeoff: if your tests are tightly coupled to a Spring Boot application context (accessing internal services, using transactional rollback between scenarios), Cucumber + RestAssured remains the right tool. Azertio is explicitly a black-box tool and does not access application internals.

vs. Karate

Karate embeds a JavaScript engine inside .feature files. You can call Java, write loops, and use conditional logic directly in feature files — which is powerful, but it means tests become mini-programs that non-technical stakeholders cannot read or validate.

Azertio enforces a clean boundary: feature files contain only declarative steps, all logic lives in typed Java step providers. The configuration model is also fundamentally different — Karate uses a karate-config.js JavaScript file for environments, while Azertio uses pure YAML profiles. Azertio also has first-class features that Karate lacks: the definition/implementation model, built-in persistence, and a dedicated VS Code extension.

The tradeoff: Karate has a larger ecosystem, more community resources, and built-in support for protocols (gRPC, WebSocket) not yet available as Azertio plugins.

vs. Postman / Newman

Postman is an excellent tool for interactive API exploration. Newman makes collections runnable in CI. The problems emerge when teams graduate to treating tests as code: Postman collections are proprietary JSON that produces noisy diffs, assertions are JavaScript scattered across collection items, and there is no database testing, no benchmark mode, and no persistent execution history.

Azertio's .feature files are plain text, fully diffable, reviewable in pull requests, and readable by business stakeholders. The two tools are not mutually exclusive — many teams use Postman for initial exploration and translate validated scenarios into Azertio for the automated regression suite.

Quick Start

# 1. Download the distribution from GitHub releases and add bin/ to PATH

# 2. Create azertio.yaml in your project
cat > azertio.yaml <<EOF
testProject:
  name: My Project
  test-suites:
    - name: smoke
      tag-expression: "smoke"
plugins:
  - gherkin
  - rest
configuration:
  rest:
    baseURL: "https://jsonplaceholder.typicode.com"
EOF

# 3. Write a feature file
mkdir -p features && cat > features/posts.feature <<EOF
@smoke
Feature: Posts API

  Scenario: Retrieve a post
    When I make a GET request to "posts/1"
    Then the HTTP status code is equal to 200
    And the response body contains:
      """json
      { "id": 1 }
      """
EOF

# 4. Install plugins
azertio install

# 5. Run
azertio run -s smoke

Where Things Stand

Azertio is in early alpha. The core runtime, the REST plugin, and the database plugin are functional; the VS Code extension is published. Protocol plugins for gRPC, GraphQL, and WebSocket are on the roadmap but not yet available.

If you are building a new test suite for API and database testing and want clean feature files, no glue code, and execution history out of the box — it is worth a look.

GitHub: github.com/org-azertio/azertio
Getting started: docs/getting-started.md

JExten: Building a Robust Plugin Architecture with Java Modules (JPMS)

Luis Iñesta Gelabert — Thu, 15 Jan 2026 16:45:48 +0000

1. Motivation: The Road to Modular Isolation

When building extensible applications in Java, developers often start with a simple question: "How can I let users add functionality without recompiling the core application?" The journey usually begins with the standard java.util.ServiceLoader, which provides a simple mechanism for discovering implementations of an interface.

However, as the application grows, a critical problem emerges: "Classpath Hell."

Imagine you have a host application that uses library-v1. You create a plugin system, and someone writes a "Twitter Plugin" that requires library-v2. If you run everything on the same flat classpath, you get a conflict. Either the host crashes because it gets the wrong version of the library, or the plugin fails. You cannot have two versions of the same library on the classpath without facing the risk of runtime exceptions such as ClassDefNotFoundError or NoSuchMethodError.

This was the driving motivation behind JExten. I needed a way to strictly encapsulate plugins so that each one could define its own dependencies without affecting the host or other plugins.

Enter JPMS (Java Platform Module System)

Java 9 introduced the Module System (JPMS), which provides strong encapsulation and explicit dependency graphs. It allows us to create isolated "layers" of modules.

Boot Layer: The JVM and platform modules.
Host Layer: The core application and its dependencies.
Plugin Layers: Dynamically created layers on top of the host layer.

By leveraging JPMS ModuleLayers, JExten allows Plugin A to rely on Jackson 2.14 while Plugin B relies on Jackson 2.10, and both can coexist peacefully within the same running application.

2. Architecture and Design

JExten is designed to be lightweight and annotation-driven, abstracting away the complexity of raw ModuleLayers while providing powerful features like Dependency Injection (DI) and lifecycle management.

The architecture consists of three main pillars:

The Extension Model

At the core, JExten uses a clean separation between the "contract" (API) and the "implementation".

Extension Point (@ExtensionPoint): An interface defined in the host application (or a shared API module) that defines what functionality can be extended.
```
@ExtensionPoint(version = "1.0")
public interface PaymentGateway {
    void process(double amount);
}
```

Extension (@Extension): The concrete implementation provided by a plugin.

@Extension(priority = Priority.HIGH)
public class StripeGateway implements PaymentGateway {
    // ...
}

Notice that you can make use of the ExtensionManager without the PluginManager. This is useful for testing or when you want to use JExten in a non-plugin environment and all the extensions are already available in the modulepath.

The Manager Split

To separate concerns, the library splits responsibilities into two distinct managers:

PluginManager ("The Physical Layer"):
- This component handles the raw artifacts (JARs/ZIPs).
- It verifies integrity using SHA-256 checksums ensuring that plugins haven't been tampered with.
- It builds the JPMS ModuleLayer graph. It reads the plugin.yaml manifest, resolves dependencies (from a local cache or Maven repo), and constructs the classloading environment.
ExtensionManager ("The Logical Layer"):
- Once layers are built, this component takes over.
- It scans the layers for classes annotated with @Extension.
- It manages the lifecycle of these extensions (Singleton, Session, or Prototype scopes).
- It handles Dependency Injection.

Dependency Injection (DI)

Since plugins run in isolated layers, standard DI frameworks (like Spring or Guice) can sometimes be "too heavy" or tricky to configure across dynamic module boundaries. JExten includes a built-in, lightweight DI system.

You can simply use @Inject to wire extensions together:

@Extension
public class MyPluginService {
    @Inject
    private PaymentGateway gateway; // Automatically injects the highest priority implementation
}

This works seamlessly across module boundaries. A plugin can inject a service provided by the host, or even a service provided by another plugin (if the module graph allows it).

3. Usage Example

Here is a quick look at how to define an extension point, implement it in a plugin, and use it in your application.

I. Define an Extension Point

Create an interface and annotate it with @ExtensionPoint. This is the contract that plugins will implement.

@ExtensionPoint(version = "1.0")
public interface Greeter {
    void greet(String name);
}

II. Implement an Extension

In your plugin module, implement the interface and annotate it with @Extension.

@Extension
public class FriendlyGreeter implements Greeter {
    @Override
    public void greet(String name) {
        System.out.println("Hello, " + name + "!");
    }
}

III. Discover and Use

In your host application, use the ExtensionManager to discover and invoke extensions.

public class Main {
    public static void main(String[] args) {
        // Initialize the manager
        ExtensionManager manager = ExtensionManager.create(pluginManager);

        // Get all extensions for the Greeter point
        manager.getExtensions(Greeter.class)
               .forEach(greeter -> greeter.greet("World"));
    }
}

IV. Package your Extension(s) as a Plugin

Finally, use the jexten-maven-plugin Maven plugin to check your module-info.java at compile time and package your extension into a ZIP bundle that includes all dependencies and the generated plugin.yaml manifest.

<plugin>
    <groupId>org.myjtools.jexten</groupId>
    <artifactId>jexten-maven-plugin</artifactId>
    <version>1.0.0</version>
    <executions>
        <execution>
            <goals>
                <goal>generate-manifest</goal>
                <goal>assemble-bundle</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <hostModule>com.example.app</hostModule>
    </configuration>
</plugin>

You can then install the generated ZIP bundle to your host application:

  public class Application {
    public static void main(String[] args) throws IOException {
        Path pluginDir = Path.of("plugins");

        // Create plugin manager
        PluginManager pluginManager = new PluginManager(
            "org.myjtools.jexten.example.app",  // Application ID
            Application.class.getClassLoader(),
            pluginDir
        );

        // Install plugin from bundle
        pluginManager.installPluginFromBundle(
            pluginDir.resolve("my-plugin-1.0.0.zip")
        );

        // Create extension manager with plugin support
        ExtensionManager extensionManager = ExtensionManager.create(pluginManager);

         // Get extensions from the plugin
        extensionManager.getExtensions(Greeter.class)
            .forEach(greeter -> greeter.greet("World"));
    }
}

4. Comparison with Other Solutions

Choosing the right plugin framework depends on your specific needs. Here is how JExten compares to established alternatives:

PF4J (Plugin Framework for Java)

PF4J is a mature, lightweight plugin framework that relies on ClassLoader isolation.

Isolation: PF4J uses custom ClassLoaders to isolate plugins. JExten uses JPMS ModuleLayers. The latter is the "native" Java way to handle isolation since Java 9, strictly enforcing encapsulation at the JVM level.
Modernity: While PF4J is excellent, JExten is designed specifically for the modern modular Java ecosystem (Java 21+), taking advantage of module descriptors (module-info.java) for defining dependencies rather than custom manifests.

OSGi

OSGi is the gold standard for modularity, powering IDEs like Eclipse.

Complexity: OSGi is powerful but comes with a steep learning curve and significant boilerplate (Manifest headers, Activators, complex service dynamics). JExten offers a fraction of the complexity ("OSGi Lite") by focusing on the 80% use case: strictly isolated extensions with simple dependency injection, without requiring a full OSGi container.
Runtime: OSGi brings a heavy runtime. JExten is a lightweight library that sits on top of the standard JVM features.

Layrry

Layrry is a launcher and API for executing modular Java applications.

Scope: Layrry focuses heavily on the configuration and assembly of module layers (often via YAML/TOML) and acts as a runner. JExten focuses on the programming model within those layers.
Features: Layrry is great for constructing the layers, but it doesn't provide an opinionated application framework. JExten provides the "glue" code—Extension Points, Dependency Injection, and Lifecycle Management—that you would otherwise have to write yourself when using raw Module Layers or Layrry.

Feature	JExten	PF4J	OSGi	Layrry
Isolation	JPMS ModuleLayers	File/ClassLoader	Bundle ClassLoaders	JPMS ModuleLayers
Configuration	Java Annotations	Properties/Manifest	Manifest Headers	YAML/TOML
Dependency Injection	Built-in (`@Inject`)	External (Spring/Guice)	Declarative Services	None (ServiceLoader)
Learning Curve	Low	Low	High	Medium

5. Conclusion

JExten is a lightweight, annotation-driven plugin framework that leverages JPMS ModuleLayers to provide isolation and dependency management. It is designed to be easy to use and understand, with a focus on simplicity and ease of use.

Finally, keep in mind that JExten is still in its early stages, and there is much room for improvement. Feel free to contribute to the project on GitHub and/or engage in a discussion in the issues section. Link to the repository is here .