On 12/5/2005 4:04 PM, Ryan Schmidt wrote:
> On Dec 5, 2005, at 13:22, Duncan Murdoch wrote:
>
>> On 12/5/2005 12:08 PM, Scott Palmer wrote:
>>
>>> On 5-Dec-05, at 11:21 AM, Duncan Murdoch wrote:
>>>
>>>> You need to have the person fixing the bug add a regression
>>>> test, and a policy that nobody commits code that fails the
>>>> regression tests. This prevents the scenario you talk about,
>>>> and also the one where someone comes along later, after the lock
>>>> has been released, and reintroduces the bug.
>>>
>>> It sounds like a good idea, until you try it is "real life" where
>>> the regression test code is 100x more complex than the feature it
>>> is testing. I've been wanting to try test driven development for
>>> years and I always come up against that roadblock. Maybe it's
>>> easier for form-based web apps or something.
>>> Sorry, off-topic. Feel free to start a new topic if there is
>>> some hope of clueing me in to the secret :)
>>
>> I think it depends a lot on the application. I'm working on a
>> language interpreter (www.r-project.org); there it is very easy to
>> put together tests, they're just code snippets in the interpreted
>> language. So much so that I wouldn't call it "test driven
>> development", as much as "test supported development". It's easy
>> to write tests and run them, so regression errors are pretty uncommon.
>
> I'd also really like to understand how to actually use such tests to
> support my development. I certainly understand that if I have a
> function multiply() which takes two arguments and multiplies them
> that I can write a test which feeds the function 6 and 7 and checks
> to make sure the answer that pops out is 42. I'm not writing
> functions like that, though, and I don't know anybody who does. I'm
> part of a team writing, among other things, a CRM system for a
> customer doing business in 16 countries. Perhaps the bug of the day
> is that the daily currency conversion rate importer didn't work. Or
> perhaps when we turn on our SQL debugging functions, then the search
> results are wrong. Or perhaps the column headers in Italian are too
> long so they wrap to the next line and mess up the layout of the
> generated PDFs. These are all things that have actually happened in
> this project, and I'm unclear how I would write a testing system that
> would have prevented any of it.
Regression tests won't prevent those the first time, but they'll prevent
re-occurrences, or similar problems. For example:
You write a test to import a currency conversion rate, check it works.
You write a test to turn on SQL debugging, check that a particular
answer is unchanged.
You measure the length of the italian column headers.
I'd say the first two would likely be useful, the last one not (because
there are lots of languages, and lots of places where the length
matters). But if the solution to the last one was to change your
formatting routines rather than to retranslate the header, maybe just
checking the Italian would be a good enough test.
The first two may never expose a regression error, but you'll eventually
have hundreds of tests like this, and in aggregate they'll actually be
pretty useful at preventing regressions. They're also of some use in
documenting boundary cases: e.g. if your program crashed when someone
entered a price of 0.0, then the regression test will document what you
think should really happen in that case.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 22:35:59 2005