How to provide Product Owner with estimates for unit testing?
Alberto last edited by
"How long does it take his developer to write a unit test?" This is exactly the question the project owners keep asking me. The question is not actually how long it takes to write the unit test, but actually what does TDD or in particular the writing of unit test bring me in the later course of development.
I always answer "That depends, some don't last very long", but as a test manager I can't give an exact specification. I always advise to use timeboxes in sprint planning.
But I am unfortunately over-questioned with this question, because the PO´s really want to have this as a calculable unit.
So how do you calculate at least a rough estimate of how long it would take per task or per sprint to write a unit test?
How do you calculate the size, and which time units ?
Bogopo last edited by
I would argue that the question will not give any meaningful information and that you should make a stand if you are questioned in your practices as a professional.
I will start by the question itself:
Uncle Bob's Three Rules of TDD:
1 - You are not allowed to write any production code unless it is to make a failing unit test pass.
2 -You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3 - You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
These rules imply that you will be "trapped" in a loop of:
1 - Writing a little piece of test (maybe simply a
MyObject obj = new MyObject()) which will break, because you don't have the class
2 - Then you create a class called
MyObject, making all tests pass
3 - Then you write some more testing:
Assert.equals(obj.name, null, "Default name is not null")
4 - Then you create an attribute called name that is always
null, making all tests pass
5 - Then you write more testing....
Each of these steps are seconds long, you keep jumping frenetically between test and production code. The act of writing tests is embedded in the act of writing production code, and vice-versa.
So, how long did it take to write this unit test? Maybe you can have a text editor plugin that tracks the time you passed writing in files in the test folder. Is this information useful? Probably not.
Maybe your PO will ask:
But we want to know if TDD has a positive ROI...
The reason we don't question doctors why they spend time cleaning their hands 10 times, with 10 strokes on each side of each finger and under the nails, it's because they are professionals (literally they do). They take responsibility on their craft.
Accountants use double entry bookkeping, which is basically the process of TDD: Making a smallest step on the assets column, then making the equivalent on the liabilities column, and checking everything is OK.
TDD is a software craftsmanship practice, it is done because it is necessary to produce high quality software, which allows changes and improvements with security that quality is not denigrated.
If the PO don't value this and prefers to deal (financially) with the consequences of badly designed software, no problem, but he/she will have a hard time dealing with professionals that value high quality of their craft.