Posts

Showing posts from August, 2010

Breaking dependencies in unit tests

"Would I use classloader magic and bytecode manipulation to set dependencies in production code? No. Would I use reflection to modify private fields in production code? No. Would I refactor to introduce an interface between objects? Yes. Would I refactor an object to get a dependency through its constructor instead of from a global variable? Yes." Nat Pryce

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 tes

IWanderAboutInterfaceNames :)

"A colleague was once accused of being so role-happy, that he defined an Integer as a combination of Addable, Subtractable, Multipliable, and Divideable.", Steve Freeman's blog

"Growing Object-Oriented Software Guided by Tests" book

"Growing Object-Oriented Software Guided by Tests" by Steve Freeman and Nat Pryce is the most useful, serious and well-written book I've read in last couple of years. It's all about TDD (test-driven development) and OOD. The book shows how unit tests evolve good OO design and how end-to-end tests let the programmer be sure that the hole system actually works. The book is not for juniors - to get the ideas work for you, you must have many years of experience as a software developer, not an architect, a project manager, a coder or whatever. Every programmer writing in any OO programmer language must read the book twice. I've done. Among others, I like the authors' conception of "test data builders" which extremely simplifies creating value type objects in tests. There's an open source library for create the builders easier - "Mare It Easy" (its .NET port is available here ). I've just tried the latter one and I realized I'll fal