[Pharo-project] Good reference on time on unit testing?

Peter Hugosson-Miller oldmanlink at gmail.com
Sun Feb 27 21:11:31 CET 2011

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 :-(


On Sun, Feb 27, 2011 at 9:04 PM, Steven Baker <steven at stevenrbaker.com>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 <norbert at hartl.name>
> 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: pharo-project-bounces at lists.gforge.inria.fr [
> pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Norbert Hartl [
> norbert at hartl.name]
> >> Sent: Sunday, February 27, 2011 5:41 AM
> >> To: Pharo-project at lists.gforge.inria.fr
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110227/8cb104ae/attachment.htm>

More information about the Pharo-project mailing list