I have asked myself this question several times, and searched for answers, without coming up with any clear answer. Therefore I have decided to go hard core TDD for a longer period of time (at least 6 months) to really evaluate the effects.
There are several things that I find confusing when it comes to TDD. One example is what actually defines a unit test. What is a "unit" anyway? After reading a bit about it I found a text claiming that the "unit" is "a unit of work", i.e. something quite small. Like converting a string to UPPERCASE or splitting a string into an ['a','r', 'r', 'a', 'y'] of chars. This work is usually performed by a single call to a single method in a single, isolated, class.
So, what does it mean that a class is isolated? Does it mean that it doesn't have any dependencies to other classes? NO! In the context of TDD it means that any dependencies are supplied by the test environment, for example by using mock objects (fakes, stubs, etc). What you are after is the ability to be able to control how the dependencies behave when being called from the class that is under test.
But how do you do that? Well one common pattern is to use is Dependency Injection (DI) and design your classes to be dependent on "contracts" (i.e. abstractions such as Interfaces) rather than concrete implementations. By injecting, abstract, dependencies rather than having each class constructing the dependencies itself, you are able to create fake, mocked, dependencies that you have total control over.
The list of things to consider in order to make your code "testable" goes on and, as you might have understood by now, forces you to structure your code very differently from how you would have done it if not considering testibility.
So, is all this worth the effort? Many claims that it is. Some claims it is just rubbish. Guess there is only one way to find out!
There are several things that I find confusing when it comes to TDD. One example is what actually defines a unit test. What is a "unit" anyway? After reading a bit about it I found a text claiming that the "unit" is "a unit of work", i.e. something quite small. Like converting a string to UPPERCASE or splitting a string into an ['a','r', 'r', 'a', 'y'] of chars. This work is usually performed by a single call to a single method in a single, isolated, class.
So, what does it mean that a class is isolated? Does it mean that it doesn't have any dependencies to other classes? NO! In the context of TDD it means that any dependencies are supplied by the test environment, for example by using mock objects (fakes, stubs, etc). What you are after is the ability to be able to control how the dependencies behave when being called from the class that is under test.
But how do you do that? Well one common pattern is to use is Dependency Injection (DI) and design your classes to be dependent on "contracts" (i.e. abstractions such as Interfaces) rather than concrete implementations. By injecting, abstract, dependencies rather than having each class constructing the dependencies itself, you are able to create fake, mocked, dependencies that you have total control over.
The list of things to consider in order to make your code "testable" goes on and, as you might have understood by now, forces you to structure your code very differently from how you would have done it if not considering testibility.
So, is all this worth the effort? Many claims that it is. Some claims it is just rubbish. Guess there is only one way to find out!
I'm back!
SvaraRaderaIntressant!
Blir spännande att följa din TDD-resa. Kan du se till att ha månadsvis uppdatering om hur det går? :)
Välkommen tillbaka :)
RaderaMånadsvis uppdatering ska ordnas.
Perfa! :)
Radera