I wrote before on TCKs - Using Mountebank to detach frontend and backend development

Mountebank by Brandon Byars is a TCP/IP technology that allows mocking of ‘downstream’ services. Most of the time that’s going to be HTTP, but it is not limited to that it could other protocols including binary. Very cool stuff, and you can program it from Ruby, Python Java (any language that can open sockets and write to them). It is distributed via NodeJS’s NPM technology but it is in no way tied to NodeJS.

TodoMVC Backend

A couple of years ago Peter Hodgson took one of the implementations of the well-known TodoMVC.com, and implemented a bunch of alternate backends for it on his todobackend.com site site. In order to guard the correctness of the each backend implementation (other people went on to provide yet more alternates), he wrote some executable specifications. Two things stand out about the specs he wrote. One is that they are “kata style” allowing newbies (implementors) to acclimiate to the contracts in stages - his project is really an educational piece. The second is that the specs optionally execute online (no setup needed for spec execution). I don’t think he has an online example of something partially passing the spec (and ultimately failing as a suite), but that would be useful for visualiztions - Pete?

What Pete has made here is one half of the TCK - the specs (tests) that verify the downstream implementation. He hasn’t made a stub implementation of the backend itself, so that writers of the front-end could verify that the TodoMVC front end is compatible. That’s too much of a challenge maybe as lots of front end technologies are very opinionated about the nature of the wire API, and you would not be able to get all of them compatible with a single mock backend serving as the refrence. Anyway, if it were possible it would allow “mix and match” like so:

This TCK idea isn’t just for UI technologies scotch-taped to backends. It is for any “downstream” services calls, even binary ones (mocking technology choice depending).

It also doesn’t matter if each technology is in a different language, as Pete’s stuff hints. You could have a Java backend, a JavaScript frontend, a suite of tests/specs in Ruby, and a mock implementation of the same in Python. It’s all good, as long as it is interchangable.