End-to-end tests and a horse in vacuum

There's a subsystem (a console app that receives tasks and sends reports via WCF). About a month ago I, influenced by GOOS book, wrote a couple of end-to-end tests for the app just before making another refactoring (yes, the app is rather messy) and adding a new feature to it. I liked how it worked.

Yesterday I did a quite big refactoring of the subsystem doing TDD. Things went really smoothly and a bunch of small, focused, loosely coupled classes were the result. At the end, when I was sure that everything is ready to launch the app, I run the end-to-end tests and (uppps) one of them was red! Good! It turned out that I added a class implementing a role interface that'd been already implemented by another one and pass the former as a dependency. The class has default fake implementation (it threw a NotEmplementedException) and cause the app to shut down in a rather rare case (which luckily was covered by the test).

What I realized from this story: we must write end-to-end tests if we want to be sure that all those nice classes really work together. Without them we're doing such a thing that Russians call "a horse in vacuum", i.e. a thing that doesn't has any practical use.

Comments

Popular posts from this blog

Computing cryptography hashes: Rust, F#, D and Scala

Upcoming F# struct tuples: are they always faster?

Composing custom error types in F#