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.
---------------------------------------------------------------------
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:06:31 2005