On 12/5/2005 12:08 PM, Scott Palmer wrote:
> On 5-Dec-05, at 11:21 AM, Duncan Murdoch wrote:
>
>> On 12/5/2005 11:02 AM, Thompson, Graeme (AELE) wrote:
>>> Yes, we have been in the situation of having files locked when people
>>> have gone on vacation, but in these cases it is possible to forcibly
>>> unlock the files and leave the developer a note, thus not stopping
>>> other
>>> working on them.
>>> More seriously, from our perspective, is the issues we have had when
>>> people have tried to merge their changes in with other peoples
>>> changes
>>> and have reintroduced bugs that have already been fixed because
>>> they did
>>> not have a full understanding of what they were doing. These bugs
>>> then
>>> take the extra time for someone to track down and then fix them
>>> again!
>>
>> 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.
>>
>> Duncan Murdoch
>
>
> 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.
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 20:26:13 2005