Paul Hammant's Blog: Speedy builds using Service Virtualization (SV) explained in diagrams
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
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.
- 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.
blog comments powered by Disqus