Cerrisian Blog

The canonical form of requirements or “behaviors” in Behavior Driven Design is something like:

GIVEN <situation> WHEN <condition> THEN <predicate>

Where <situation> describes the state of the system and <condition> describes what’s actually happened to cause the system to express a behavior. <predicate> verifies that the correct behavior occurred.

Uncle bob says that this is a finite state machine in English, which is true, but it also has a similarity to the black box specifications of cleanroom:

Now, this is a step before the finite state machine, that’s called a “state box” in Clean Room parlance.

Clean Room separates this stimulus history driven black box from the state machine to maximize the flexibility in allowed implementations. The idea is to start with some natural language entries in the black box description and go through discussion with the client, as this is happening, stimulus histories are generated using combinatorics to make sure that all possible histories are covered.

This guarantees something called “referential transparency”, which basically means that the black box specification is complete and preserved at all levels of “detailing” and implementation.

This doesn’t deal with the ambiguity of human language, but gives specifications some structure that should help turn it into procedure and code.

Test Driven Development (TDD) creates code from concrete examples of inputs and expected results (outputs/state changes).

Clean room software engineering creates code and design from stimulus history and expected responses. It’s the same concept but with additional mathematical rigor.

What do you do if you have an existing implementation that does what you want but the code is messy? First, find a testable interface against the old code, then create a set of test cases against it (potentially automatically generated) and use that as your test oracle when doing code implementation.

Here’s an example. Say that you have an awesome algorithm implemented in some horrid code on a platform that isn’t very portable, say some code in MATLAB that calculates the cuteness of kittens. Now you want to have this implementation in a language that’s deployable, say NumPy. Now, the code is horrible so you cry every time you see it, but it’s correct because it was written by the foremost psycho-physicist specializing in feline cuteness.

So you whip up a test case generator that feeds in a bunch of pictures of kittens and uses the MATLAB code’s results as ground truth. From there you basically have a complete black box description of the system and can hack away.

This is the same as TDD, but you don’t do the work of figuring out the expected results from the inputs yourself.

I really should try this out on a project sometime, perhaps PyGP again.