Online-Test-Driven Development

This picture depicts what the tests look like and how they are run in OTDD.

Online-Test-Driven Development (OTDD) is a development process based on the idea of TDD. It focuses more on how to utilize the online network data for testing and mainly applies on microservice development.

OTDD is developed mainly because of the TDD limitations and the popularity of microservice.

TDD is practically not very flexible when applying on microservice, which becomes very popular recent days, because it involves many third-party dependent network services that need to be mocked, which makes writing a test can be hard. Tests writing are time-consuming and the quality of the test base is not guaranteed as different developers can hardly ensure the quality of tests at different time consistently.

In OTDD, however, online network data are continually recorded into tests. The tests consist of data rather than code and are recorded online automatically, therefor there is no longer the need to write the whole test base. Third-party dependent network services are mocked automatically using the online network data recorded when the test is run, making the service run as if it were online. If needed, a new test can be written based on recorded online test and discarded when code is deployed online as new tests will be recorded automatically. The quality of the test base is high consistently as they are online network data without pollution.

OTDD not only helps coping with the tests themselves, but also helps constructing all the dependent data necessary to do a test, it will fasten the development phase considerably.

OTDD is firstly introduced by JieYe, a Chinese software engineer, in his book "OTDD, Online-Test-Driven Development, the improved TDD applying on microservice development".

The OTDD Steps

With the limits of TDD and the microservice development in mind, OTDD upgrades the steps involved. The main steps in OTDD are:

1.tests are continually recorded online

2.new test is written first, but based on online test recorded previously

3.see if the new test fails, it's ok not to run all tests here

4.write the code

5.run the new test

6.refactor new code and repeat 5

7.run all tests

8.code is deployed and new test is discarded

How tests are recorded

A test consists of the client request and the corresponding third-party network requests and responses and the client response. Normally the online network data looks like this:

This picture depicts how the online network data look like normally.

The most import thing is how to correlate them into individual tests. Basically There is no information to correlate them, we may think adding something like a trace id to the client request and response and its corresponding dependent third-party requests and responses, but the TCP protocol have no room for it, we can only add it to the application protocol layer. It's hard to add all the id at the application level as we need to pass the id whenever it involves network calls, not to speak some application protocols like redis or mysql protocol have no room for the id either. So this solution is not flexible.

The solution is to introduce a time gap to do the correlation as shown below.

This picture depicts how the time gap is introduced and how the client request / response and third-party requests / responses are correlated by it.

The figure above shows how a time gap is introduced and how the online network data are recorded into tests. Think about that a microservice is sent one client request, it processes the request and returns the response, after the time gap when response is sent back, one minute for example, it is sent another client request. Please note that the second request is not standing there waiting the whole one minute, it's another request that happens to arrive and is picked and sent here one minute later.

Though this arrangement, client requests are processed serially and no two client requests are being parallel processed during the the whole process. Then we can safely correlate the client request and response with the third-party requests and responses between the time gap.

How tests are run

The tests are run by the OTDD platform. When a test is run, the client request in the test is firstly sent to the microservice, the third-party calls are mocked by the platform using the data in the test, the client response from the microservice is received by the platform. From the microservice's perspective, it is sent an online client request, and the third-party calls succeeded just like online, it then sent back the client response.

This picture shows how the tests are run.

Before the tests are run, the iptables rules are setup first, forcing all new out going connections to go through a local proxy. The local proxy then redirects the request to the test mock.

How tests are written

When there is a need to write a new test, it can be written based on existing online test.

This picture shows how the tests are written. How it can be modified.

A language called OTDD Data Description Language is introduced to help modify the request or response, as them may be in binary format that can be hardly modified directly.

Benefits

1.Time Efficiency

Tests base are no longer written from scratch but are recorded automatically. New tests are added automatically after code is deployed online. These features save a lot of time spent on writing and managing tests.

2.Improved Confidence

Tests are online data that can be trusted, this will make us be more confidence about our code. The diversity of the online data also makes the test base having a high coverage, which means the regression can make us very confidence.

3.Making Self-Testing Easy

In traditional microservice development, self testing can be a problem.

While decomposing an application into different smaller microservices improves modularity and makes it easier to develop, at the same time, it makes it harder to test as it brings considerable dependencies.

In a most simple example, an application with no dependencies can be tested very easily as there is no dependent data, we need not to prepare them. We just need to send the request and check the response. However, after the application is decomposed into two microservices, testing them becomes harder. At the perspective of one microservice, it depends on another microservice. Testing the microservice is no longer as simple as to send the request and check the response. The dependent microservice must be started up, and the request and response between the two microservices need to be checked too.

It becomes out of control and turns into a disaster when the number of microservices grows great, let's say twenty. When there are twenty microservices out there having some degrees of inter-dependency, which is commonly seen in a medium-scale internet company, testing one of the microservices becomes extremely hard. It's hard to prepare all the twenty microservices. It's hard to prepare all the data in the twenty microservices. It's hard to ensure the stability of all of them. What makes it worse is that, they are probably developed and owned by twenty different groups of developers.

The test in OTDD helps us cut the inter-dependency during the test. All dependent data are mocked. We no longer need to prepare the twenty microservices. We no longer need to prepare the data in the twenty microservices, they are prepared better by the test using online data. We no longer worry about the stability of the twenty microservices. We no longer need to care about who developed the other microservices.

Limitations

OTDD still has its limits. It is most suitable for microservice development. For other types of applications, for example, a hadoop or spark application, or a background batch application, the OTDD can not be applied.

OTDD Platform

As in TDD, various kinds of tools or frameworks, for example various unit test frameworks, are used to support TDD, we need an OTDD platform to support OTDD too. Currently the OTDD platform is under development and will be released soon.

Online-Test-Driven Development

This article "Online-Test-Driven Development" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Online-Test-Driven Development. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

---