Steven, you're making perfect sense to me, and I think almost everyone here agrees with you.
Bill's problem (if I've understood him correctly) is that he needs to convince some pointy-haired-boss-type person, by directing him or her to a well-respected "official" statistic that "proves" what we all know to be true from experience. Sadly, I think it will be hard to find it :-( -- Cheers, Peter On Sun, Feb 27, 2011 at 9:04 PM, Steven Baker <[email protected]>wrote: > I've always felt that "test driving" code actually results in negative > time spent on "testing". I spend (and everyone I know that tests well > does as well) a lot less time writing code test-first than I ever > would writing the same code without the tests first. Also, I spend far > less time (almost none) manually testing functionality. So TDD results > in net negative time difference. > > (Apologize if I'm incoherent, the cold and flu drugs are strong in this > one.) > > -Steven > > On Sun, Feb 27, 2011 at 11:51 AM, Norbert Hartl <[email protected]> > wrote: > > > > On 27.02.2011, at 13:58, Schwab,Wilhelm K wrote: > > > >> 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. > >> > > It seems I wasn't clear on this one. I'm trying to making a point that > there is no distinction between "testing" - "no testing" but between > "testing" - "writing tests". If you take compilation you test the code for > syntax and language quirks. If a developer runs the program he develops than > he is testing already. Testing and running a program is the same form that > point of view. He takes input parameter and expects output parameter. That > is testing. The point is just that developers do it manually and that is not > reproducable. So there is no real difference between manual testing all the > time and written test case. Only that repeating the testing procedure is > boring and therefor supposed to be done by a machine. So if developers could > see that the just need to put the work they already doing into a test will > ease the work without changing much. They are just changing style and save > time. That's it. Talking about 100% test coverage and holistic views about > what the perfect testing could be doesn't help. > > > >> 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? > >> > > I understand your intention but the view is inapropriate. Coding and > testing aren't two things. It is something that belongs together (if you > changed coding style). So that's why it is hard to estimate a time that > should be spent. To me it is more comparabale to this: We all know > collections are great. Imagine someone asking you "Can anyone recommend a > good reference on the amount of time one should expect to spend writing code > that uses collections?". What would you say? There is no answer. That > doesn't mean you can't solve the problem. But you won't solving it by saying > "It is 38.345 % of the time". If people don't get it you have to convince > and/or teach them. I had several times where I could show the developer that > he is gaining time from doing it. That works. Everything else is targeted > towards excel manipulators. > > > > Norbert > > > > > >> ________________________________________ > >> 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 >
