Servirtium in Technology Compatibility Kits

Unilateral: without the cooperation of the maker/supplier/vendor of the "real" service.

First you perfect you tests in "direct" and "recording" modes.

Then, once happy with the recordings in Markdown, configure tests to use "playback" of Servirtium recordings as a default.

If the build is a recursive multi module build (Maven and Gradle builds often are), or if the build is a directed graph type (Buck and Bazel), then with build-flags, tests will run utilizing the markdown recordings previously commited to source-control.

Main Build Server job Definition

You setup your build server to guard/verify your team's Continuous Integration claims by building every commit/push to trunk/master using this default "playback" mode.

You also configure the pipelines of the build server to verifying "pull requests" (or equiv) in the same way (playback of Servirtium recordings). You know, commits that have not yet been merged (integrated) into master/trunk, but are ready for code review.

Second Build Server Job Definition

In another nightly (or weekly) build server job definition (not at all guarding CI) configure it to re-record the Servirtium markdown recordings. This may need credentials, which should be passed in as secrets the build server knows and not hard coded in source control in any way.

At the end of this job, you need to perform a check that the recording has not changed in any significant way. Here's some bash script that'll perform that for a Git transient checkout associated with the build job:

theDiff=$(git diff --unified=0 path/to/module/src/test/mocks/)

# optional ‘sed’ tricks above too if you want
# for example sed '/FooDate/d' will delete lines that contain 'FooDate'

if [[ -z "${theDiff}" ]]
then
      echo " - No differences versus recorded interactions committed to Git, so that's good"

else
      echo " - There should be no differences versus last TCK recording, but there were - see build log :-("
      echo "**** DIFF ****:${theDiff}."
      exit 1
fi

It will fail the build job, hopefully causing human investigation and preventing you from sending something live that has service incompatibilities. If there's enough time that is - your release cadence is daily or slower.

Bilateral: Full TCK with the cooperation of the maker/supplier/vendor of the "real" service.

The maker owns service spec, with many licensees/clients or downstream users.

In this case the maker/supplier/vendor of the real service, ships you Servirtum markdown recordings for agreed test scenarios. They will also ship unit tests that pass for the recordings or the real, using Servirtium technology.

The vendor and you (the client) cooperate on the service spec, with them implementing it, and you using it.

You're both developing against a schedule. You're going to have the Servirtium markdown recordings in a repo with tests that is outside the vendors regular source repo and outside yours too. The tests are playback only in that repo from the clients point of view and always pass. The client proposes changes to the spec/contract with pull-requests. The vendor accepts this with merge actions, or comments on them in the code-review tool (GitHub and others have built in code-review) towards conclusion.

Similarly the vendor proposed changes to the spec in the same style. The vendor has the opportunity to re-record the markdown recordings for the proposed pull-request. They do this, if they had already tentatively upgraded the service within their own codebase. Of course they are making a pull-request in this shared repo for the client to review, and it might be rejected if not debated towards mutual satisfaction.

This way of working between vendor/client could be a very low overhead way of working - meetings and conf calls have been minimized or eliminated. Documents purporting to be specs have definately been eliminated.