index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>OpenTestingAPI</title><link>https://opentestingapi.github.io/</link><description>Recent content on OpenTestingAPI</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 03 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://opentestingapi.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Version 1.0</title><link>https://opentestingapi.github.io/specification/version-1.0/</link><pubDate>Fri, 16 Sep 2022 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/specification/version-1.0/</guid><description>OpenTestAPI Specification [Download JSON Schema Specification]
Disclaimer Part of this content has been taken from the great work done by the folks at the [AsyncAPI] initiative and the [OpenAPI] initiative.
Introduction The OpenTestAPI specification is a project to describe and document tests cases in a machine-(and human-)readable format. The specification defines a set of files to describe a test case. Creation and execution of the test cases can be done by utilities.</description></item><item><title>Introduction</title><link>https://opentestingapi.github.io/getting-started/10_introduction/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/getting-started/10_introduction/</guid><description>A typical modern application development:
A modern architectures is often build of several (up to hundreds) of connected services with huge amount of different technologies for communication and persistence Typical system- and integration test are build by developers using the technology, which is the base for the service implementation. In best case End-to-End testing (E2E) is done by dedicated testers using standard tools sticking to a few technologies. Typical E2E Tests are one time shots: Start, Run, Destroy Drawbacks of the current approach:</description></item><item><title>Version 1.1</title><link>https://opentestingapi.github.io/specification/version-1.1/</link><pubDate>Mon, 13 Mar 2023 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/specification/version-1.1/</guid><description>OpenTestAPI Specification [Download JSON Schema Specification 1.1]
Disclaimer Part of this content has been taken from the great work done by the folks at the [AsyncAPI] initiative and the [OpenAPI] initiative.
Introduction The OpenTestAPI specification is a project to describe and document tests cases in a machine-(and human-)readable format. The specification defines a set of files to describe a test case. Creation and execution of the test cases can be done by utilities.</description></item><item><title>Version 1.2</title><link>https://opentestingapi.github.io/specification/version-1.2/</link><pubDate>Mon, 05 Jun 2023 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/specification/version-1.2/</guid><description>OpenTestAPI Specification [Download JSON Schema Specification 1.2]
Disclaimer Part of this content has been taken from the great work done by the folks at the [AsyncAPI] initiative and the [OpenAPI] initiative.
Introduction The OpenTestAPI specification is a project to describe and document tests cases in a machine-(and human-)readable format. The specification defines a set of files to describe a test case. Creation and execution of the test cases can be done by utilities.</description></item><item><title>Version 1.3</title><link>https://opentestingapi.github.io/specification/version-1.3/</link><pubDate>Wed, 09 Aug 2023 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/specification/version-1.3/</guid><description>OpenTestAPI Specification [Download JSON Schema Specification 1.3]
Disclaimer Part of this content has been taken from the great work done by the folks at the [AsyncAPI] initiative and the [OpenAPI] initiative.
Introduction The OpenTestAPI specification is a project to describe and document tests cases in a machine-(and human-)readable format. The specification defines a set of files to describe a test case. Creation and execution of the test cases can be done by utilities.</description></item><item><title>Version 1.4</title><link>https://opentestingapi.github.io/specification/version-1.4/</link><pubDate>Wed, 09 Aug 2023 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/specification/version-1.4/</guid><description>OpenTestAPI Specification [Download JSON Schema Specification 1.4]
Disclaimer Part of this content has been taken from the great work done by the folks at the [AsyncAPI] initiative and the [OpenAPI] initiative.
Introduction The OpenTestAPI specification is a project to describe and document tests cases in a machine-(and human-)readable format. The specification defines a set of files to describe a test case. Creation and execution of the test cases can be done by utilities.</description></item><item><title>Version 1.5</title><link>https://opentestingapi.github.io/specification/version-1.5/</link><pubDate>Thu, 10 Aug 2023 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/specification/version-1.5/</guid><description>OpenTestAPI Specification [Download JSON Schema Specification 1.5]
Disclaimer Part of this content has been taken from the great work done by the folks at the [AsyncAPI] initiative and the [OpenAPI] initiative.
Introduction The OpenTestAPI specification is a project to describe and document tests cases in a machine-(and human-)readable format. The specification defines a set of files to describe a test case. Creation and execution of the test cases can be done by utilities.</description></item><item><title>Version 1.6</title><link>https://opentestingapi.github.io/specification/version-1.6/</link><pubDate>Tue, 03 Feb 2026 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/specification/version-1.6/</guid><description>OpenTestAPI Specification [Download JSON Schema Specification 1.6]
Disclaimer Part of this content has been taken from the great work done by the folks at the [AsyncAPI] initiative and the [OpenAPI] initiative.
Introduction The OpenTestAPI specification is a project to describe and document tests cases in a machine-(and human-)readable format. The specification defines a set of files to describe a test case. Creation and execution of the test cases can be done by utilities.</description></item><item><title>End-To-End Testing</title><link>https://opentestingapi.github.io/getting-started/20_e2etesting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/getting-started/20_e2etesting/</guid><description>Testing End-to-End (E2E) testing describes an approach which tests a system from its beginning to its end. Each software system has at least one mission. The system is taking input data, processes this data and generates some output data. It&amp;rsquo;s as simple - really. A system without these simple steps is a system without a mission - it&amp;rsquo;s a useless system.
Processing can be quite simple, take data from a place and put it to another one.</description></item><item><title>Why a Testing API?</title><link>https://opentestingapi.github.io/getting-started/30_whyanapi/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/getting-started/30_whyanapi/</guid><description>A new project results in a new testing approach, depending on the used technology and the people working. Someone has experience with tool X, another one has already licenses for tool Y and another project member likes to approach to do everything from the scratch and new. In best case you can find a common solution fitting all your requirements to develop a good test practice. In worst case you find a huge set of tests, which can not be executed or further improvement results in huge efforts.</description></item><item><title>Hello World</title><link>https://opentestingapi.github.io/getting-started/40_hello-world/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/getting-started/40_hello-world/</guid><description>Let&amp;rsquo;s start with a simple test case example. In general a testcase consist of 2 sections, a section describing the input for our system under test (SUT) and a section describing the output validation. In addition, a few meta information to identify the test case has to be added. With this, a minimal test cases frame looks like:
{ &amp;#34;testapi&amp;#34;: &amp;#34;0.1&amp;#34;, &amp;#34;id&amp;#34;: &amp;#34;hello_world_test&amp;#34;, &amp;#34;description&amp;#34;: &amp;#34;my first hello world test, showing how its working&amp;#34;, &amp;#34;injections&amp;#34;: [ .</description></item><item><title>Reference Implementation</title><link>https://opentestingapi.github.io/tooling/refimpl/</link><pubDate>Mon, 25 Oct 2021 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/tooling/refimpl/</guid><description>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.</description></item><item><title>About</title><link>https://opentestingapi.github.io/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://opentestingapi.github.io/about/</guid><description>Learn more and contribute on GitHub.</description></item></channel></rss>