Question

I’m fairly green to unit testing and TDD, so please bear with me as I ask what some may consider newbie questions, or if this has been debated before. If this turns out to be considered a “bad question” (too subjective and open for debate), I will happily close it. However, I’ve searched for a couple days, and am not getting a definitive answer, and I need a better understand of this, so I know no better way to get more info than to post here.

I’ve started reading an older book on unit testing (because a colleague had it on hand), and its opening chapter talks about why to unit test. One of the points it makes is that in the long run, your code is much more reliable and cleaner, and less prone to bugs. It also points out that effective unit testing will make tracking and fixing bugs much easier. So it seems to focus quite a bit on the overall prevention/reduction of bugs in your code.

On the other hand, I also found an article about writing great unit tests, and it states that the goal of unit testing is to make your design more robust, and conversely, finding bugs is the goal of manual testing, not unit testing.

So being the newbie to TDD that I am, I’m a little confused as to the state of mind with which I should go into TDD and building my unit tests. I’ll admit that part of the reason I’m taking this on now with my recently started project is because I’m tired of my changes breaking previously existing code. And admittedly, the linked article above does at least point this out as an advantage to TDD. But my hope is that by going back in and adding unit tests to my existing code (and then continuing TDD from this point forward) is to help prevent these bugs in the first place.

Are this book and this article really saying the same thing in different tones, or is there some subjectivity on this subject, and what I’m seeing is just two people having somewhat different views on how to approach TDD?

Thanks in advance.

Answer 1

Unit tests and automated tests generally are for both better design and verified code.

Unit test should test some execution path in some very small unit. This unit is usually public method or internal method exposed on your object. The method itself can still use many other protected or private methods from the same object instance. You can have single method and several unit test for this method to test different execution paths. (By execution path I meant something controlled by if, switch, etc.) Writing unit tests this way will validate that your code really does what you expect. This can be especially important in some corner cases where you expect to throw exception in some rare scenarios etc. You can also test how method behaves if you pass different parameters – for example null instead of object instance, negative value for integer used for indexing, etc. That is especially useful for public API.

Now suppose that your tested method also uses instances of other classes. How to deal with it? Should you still test your single method and believe that class works? What if the class is not implemented yet? What if the class has some complex logic inside? Should you test these execution paths as well on your current method? There are two approaches to deal with this:

• For some cases you will simply let the real class instance to be tested together with your method. This is for example very common in case of logging (it is not bad to have logs available for test as well).
• For other scenarios you would like to take this dependencies from your method but how to do it? The solution is dependency injection and implementing against abstraction instead of implementation. What does it mean? It means that your method / class will not create instances of these dependencies but instead it will get them either through method parameters, class constructor or class properties. It also means that you will not expect concrete implementation but either abstract base class or interface. This will allow you to pass fake, dummy or mock implementation to your tested object. These special type of implementations simply don’t do any processing they get some data and return expected result. This will allow you to test your method without dependencies and lead to much better and more extensible design.

What is the disadvantage? Once you start using fakes / mocks you are testing single method / class but you don’t have a test which will grab all real implementations and put them together to test if the whole system really works = You can have thousands of unit tests and validate that each your method works but it doesn’t mean they will work together. This is scenario for more complex tests – integration or end-to-end tests.

Unit tests should be usually very easy to write – if they are not it means that your design is probably complicated and you should think about refactoring. They should be also very fast to execute so you can run them very often. Other kinds of test can be more complex and very slow and they should run mostly on build server.

How it fits with SW development process? The worst part of development process is stabilization and bug fixing because this part can be very hardly estimated. To be able to estimate how much time bug fixing takes you must know what causes the bug. But this investigation cannot be estimated. You can have bug which will take one hour to fix but you will spend two weeks by debugging your application and searching for this bug. When using good code coverage you will most probably find such bug early during development.

Automated testing don’t say that SW doesn’t contain bugs. It only say that you did your best to find and solve them during development and because of that your stabilization could be much less painful and much shorter. It also doesn’t say that your SW does what it should – that is more about application logic itself which must be tested by some separate tests going through each use case / user story – acceptance tests (they can be also automated).

How this fit with TDD? TDD takes it to extreme because in TDD you will write your test first to drive your quality, code coverage and design.