Another quick video about adding tests to an existing project. If you haven’t seen last time’s video go check it out now!
The project I’m working on is a Micro ORM and you can find it on Debonair.
To Break or Not To Break
For the last video I selected a nicely isolated class in order to start building the characterization tests fast without loosing too much time dealing with dependencies (I do that every day at work).
This time I decided to cover a class that had a strong dependency to a static method in the constructor of the class. Some people treat dependencies as death sentences:
the code is un-testable so why bother?
That an excuse! that only means they are lazy and they didn’t want to add the tests in the first place.
But dealing with a dependency like this in C# is fairly simple and you can free yourself by simply putting the dependency in a protected method that you will the override in a child class that you use to test. This is the Subclass to Test Pattern and you can find more about it here.
After breaking the dependency I build a stub for it and started building the tests but after a while the tests become difficult to manage so I decided to try another rounte.
Instead of breaking the dependency I left it there and continue with my tests. Then something happened…
The morale of today’s video is that you should strive for simplicity, even when you write your tests, if you don’t want to end up with a huge un-maintainable mess.
Author: Daniele Pozzobon
He constantly annoys his friends by talking about software and is passionate about Agile methodologies, which gives him more opportunities to talk annoy his friends even more.
When there are no friends around to annoy, he blogs on CodeCleaners and in his free he time loves go hiking with his wife and two daughters.