A primary goal when spending time tweaking builds is speed. Speed for developers (and QA automators), as well as speed for the CI Servers checking things after commits happen.

Builds should include the running of functional UI tests (WebDriver) that in the present age means the leveraging of service virtualization (wire-mocking). This build should all be functionally consistent with the production environment, and is allowed to be non-functionally dissimilar to prod. At least in the earlier ‘fail fast’ stages of the build.

As a reminder, build stages should roughly be compile, unit test, integration test, function UI component test, and fuller-stack end to end tests (possibly happy path). We’ll assume the compile and unit test phases are fast, stable, and have a high test coverage.

Testing two tiers, and mocking a third

(outer boxes are processes on one machine - localhost)

Here there is a standalone web server that hosts the application (static and dynamic). The downside is that the server process has to be started and stopped in the build, and that its payload (a WAR file for Java web apps) has to be fully or partially prepeared. Longer build times and a small risk of fragility are the price.

What we really want is to embed the server in the test runner, to speed things up, and allow many fine-grained choices in testing:

Reducing the number of processes involved in a build is always good generally, and always makes things faster.

Testing the top tier, and mocking the web server

If the webserver logic is anemic, then it could be the perfect seam to focus on for wire mocking:

Technology Compatibility Kit Style Double Check

Teams should rightly fear that their virtualized service and its real equivalent drift apart over time. It is important to have a CI tested confirmation that the two are in step:

This ends up being a Technology Compatibility Kit (TCK).