Bear with me, four biggish diagrams in this article. They hopefully shorten a otherwise lengthy explanation to something that at least should move you to “we should do this too”.

Imagine you have an application stack that looks like this:

Say you’ve chosen AngularJS or Angular for the front end, and Java for the “Backend for Frontend” (BFF). You could easily split your build into two. If you additionally mix in a service virtualization framework, then you can move to a higher speed build while simultaneously increasing the verification of the correctness of the stack pre-deployment. Well, if you add in a third build (detailed later).

You can go either way on deploy-in-lockstep or deploy independently for those two pieces. The latter comes with additional integration testing complexities, that are not so hard to solve.

Note: My old employer, ThoughtWorks, introduced me to the “BFF” acronym (after I left).

UI (Frontend) build

A classic Grunt style build running trough tests as fast as possible. The comprehensive UI tests performed by Protractor/WebDriver can be super fast if you focus on the smallest rectangle that contains the thing you’re wanting to test. I went into that in UI Component Testing.

Note: none of the test steps here are production-like. We’re sacrificing that for speed.

BFF (Backend for Frontend) build

The blue-ish “Mb” wire protocol is Mountebank’s HTTP programming API, but I did not have enough room to write all that in the diagram. Service virtualization can be can be kick started (or kept fresh) by using the framework to record requests and responses over the wire. You can use a spec for REST with RAML too, for extra validations.

Note: none of the test steps here are production-like. As before we’re sacrificing that for speed.

TCK (Technology Compatibility Kit) build

Here’s where we gain some confidence that the binaries made by the two builds above. First, in a counter-intuitive step, we check the service virtualization mock technology from the UI build with the headless BFF integration tests of the BFF build. They should all pass even though they are comprehensive. The eagle-eyed will have noticed that the complexity here is that the Mountebank mocks were programmed from JavaScript in the UI build, yet the tests from the BFF build are in Java (at least for our hypothetical stack). I’ve not personally solved that, but I would imagine that I would find a way to make it work.

There’s a smoke suite too - just to make sure the thing works in a full-stack configuration.

And that last step here should be production-like. We’re sacrificing speed for consistency with production, for this final test. Not every build step needs to be production like - that’s a false god.

More reading

• Shared-Nothing Builds
• Service Virtualization Strategies For Fast Builds
• A 16 Second Java Webapp Build (Including WebDriver Tests)

On TCKs specifically

• More on technology compatibility kits in app development
• Using Mountebank to detach frontend and backend development

If not Mountebank

I’ve most experience with Brandon Byars’ Mountebank, but there are other choices too - see the bottom of Wire Mocking Without A Service Virtualization Framework.