Let’s take a hypothetical situation: our motor vehicle assembler is designing a new car concept. Everything works in slightly different ways than the usual.

We’ve performed the steering wheel unit test, and everything works fine. Now we have to test how it integrates with the whole car. So we’re gonna design an acceptance test, using a real car to see whether the wheel can turn the car left and right properly or not.

But we want to test only the steering wheel behaviour, so we decided to use a partial car for testing it. The partial car may have no gear, or any engine neither. We don’t need’em, we just wanna see whether the steering wheel does its job.

What a humongous mistake! The partial car’s behaviour is far different from the real one’s. So the mistaken acceptance test runs fine, but the steering wheel may not be able to turn a real car in time or at the right turn.

This weird example is an analogy for how I’ve seen people writing acceptance tests (and calling them “integration tests”).

Because of a misunderstanding of the FSM, software designers think there can be allowed to create inconsistent-state models in order to change that state little by little through a procedure chain, hoping they get into a consistent state at the end.

This approach allows testing code actors by faking the environment with inconsistent models, which does not represent the production behaviour anyhow.

The ungeared or nonengined car is the outre sample of an inconsistent-state model. No acceptance test like it can reflect the real one’s behaviour, thus it’s not reliable.

The fix is the functional approach of the Immutability Constraint. Absolutely no model can exist in an inconsistent state, even from its very first creation.

You’re not obliged to use a functional language, like Erlang, Scheme, OCaml, or Haskell, to stick to the functional constraints. You just need to stick. It’s a mindset.

You can be functional in Javascript, Python, Ruby (hardly), even Java and C. Of course some resources are not available, but you’re gonna need to make some concessions. Be reasonable.

Being immutable, you cannot allow inconsistent models anywhere at all. Every just-born model must be consistent, if it’s not, an exception should be raised right at once, breaking the flow up. Since it’s immutable, it’ll be always consistent.

This approach fully avoids “no-gear” and “engine-missing cars” in the code, forcing the acceptance tests to depict the real world as closely as possible and making them reliable.

Also in Medium.