Norbert, Excellent points - I take exception with only one: you assume that all developers test - that is sadly not true. I am involved with a group who seem to think that a handful of tests added at the last minute will somehow magically fix their problems.
I have no problem arguing that testing (if done well) can/will reduce overall development time; the question is how much of that time one should expect to devote to writing and maintaining unit and acceptance tests? Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Norbert Hartl [[email protected]] Sent: Sunday, February 27, 2011 5:41 AM To: [email protected] Subject: Re: [Pharo-project] Good reference on time on unit testing? Hi, On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: > Hello all, > > Can anyone recommend a good reference on the amount of time one should expect > to spend writing tests? I will have to be the messenger (will be wearing > running shoes just in case...), but I want the message to come from a solid > source. I find that really hard to answer. To me the problem is the question itself. I heard the "..amount of time one should expect to spend writing tests?" so often in companies and I think it was always exactly this phrase. While the question is valid it gives the impression there is something that decucts time from your "normal" development work. So the people that are asking this question are often managing people that have read something about code quality and they want to apply _this_ to their teams. The definition over time is troublesome, too. Testing is not easy. Everything you read about testing gives you the impression that everyone knows how to test and that those developers are just too lazy. And that is not true. Most developers I met had problems to see what testing is all about. The don't see interfaces as provable promises etc. So if you tell any of these developers they should spend 1 hour a day in testing than you will get tests that are counter-productive. My favorite example is the one where you have any composite object with an add method. Than the test goes like adding something via the interface and then try to access the internal array and check if it is of size 1. To me it is the same as with documentation. I prefer to have less documentation than useless documentation. So every developer is testing in some way. You either test and debug on the way in an unstructured form or you write tests. To me writing tests is not an add-on it is a change in working style. From this point of view I would state that the time I need to spend _additionally_ for testing is negative. I grew up with a print statement being the ultimate debugging tool. A print/debugging statement is added at the time of debugging and probably removed if the error seems to be fixed. That can lead to a situation where you do this multiple times. Writing the same as a test (and that forces you to produce more fine grained code) you will have a saving in time and a little assurance about regression. Regression debugging (debugging it again later) is much more time spent because you have to fix the error _and_ you need to focus again on that problem (which takes most of the time). So the point in writing tests is not to spend time but to save time. The amount of time one should expect to spend writing tests is less than the time you need to spend for testing otherwise. :) Norbert
