OpenTestingAPI

Version 1.5

Application Testing for Everyone

Reference Implementation

Technology Stack

Our main goal is to make the test solution as easy to use as possible. In addition, it should be possible to extend the existing solution according to our own needs. For this reason we have chosen the widely used technology Spring Boot and Java.

Repository: https://github.com/opentestingapi/impl_java

There are 3 options for use:

Container (preferred usage)

You can use all of the preexisting adapters, no need to deal with source code itself.

https://github.com/opentestingapi/impl_java/pkgs/container/opentesting

Extend the always latest version in retrospect

You can use all of the preexisting adapters, implement custom ones and inject into the latest source code as an addon.

https://github.com/opentestingapi/impl_java_extension

Fork the project

You can fork our project, but you need to take care of new versions and API updates on your own.

Features

Available Adapters: https://github.com/opentestingapi/impl_java#adapters

In addition to the main functions defined in the API, the reference implementation provides some extensions:

Metrics and Grafana Dashboard

Expose metrics for Prometheus and Grafana, including Grafana Dashboard

Example

API including Swagger UI

Communication should be API based, so we offer a huge list with API endpoints including Swagger UI.

https://github.com/opentestingapi/impl_java#api-usage

  • test case scheduling
  • reporting (export)
  • trigger injects manually
  • password encryption and decryption
  • filter / search log
  • pause test case execution

Pipeline Integration

For a pipeline integration you need a defined start time for test cases and the possibility to check the results later. API offers additional endpoints to realize this “one-time-shot” feature as bulk execution of defined injects. All subsequent injects/checks of the triggered injects are taken into account and the result can be determined on the basis of the bulk ID. By the possibility to define checks as not mandatory, the behavior of the pipeline can be adapted accordingly.

https://github.com/opentestingapi/impl_java#pipeline-integration--bulk-execution

JUnit Integration

You can use Testcontainers to startup our ref implementation during test phase with JUnit. Using this approach it is possible to write system and system integrations tests with OpenTestingAPI!

https://github.com/opentestingapi/impl_java_testcontainers

BTW Here you can find a cool example to startup a local development environment powered by Testcontainers.

Preventing the locking of credentials

We have introduced a cache to stop repeating execution of wrong credentials. Locked credentials could be simply unlocked by re-uploading the test case. It can be disabled using the feature toggle in the properties, this can be useful for tests during non-zero-downtime deployments.

Tracing

TraceID from Brave is stored for every check and can be exported, Zipkin configuration is available.

Templating

Templating is not really a feature of the reference implementation, but here you can find a way to do it easily with the Linux shell. For example, Connect information of the different stages can be managed and reused externally.

https://github.com/opentestingapi/impl_java/tree/master/scripts/json_template

Last updated on 25 Oct 2021
Published on 25 Oct 2021
 Edit on GitHub