Do you TDD for debugging fix?

views:

306

answers:

+4 Q:

Do you TDD for debugging fix?

Hi, I know there's a lot of stuff on TDD and i'm trying to pick up the practice too. But i wonder is it a good idea to to TDD your bug fix too?

I was thinking along the lines of find the bug and narrow it down. Write unit test to ensure that it will now pass whatever problem that it previously caused. Write more unit test for other breakable conditions. And finally write unit test to test for Integration test, as we don't have any unit test prior to this, so whenever i'm fixing a bug i'm always worried that i might accidentally break something.

So is TDD suitable for debugging too?
Or is there other method or resource/book that would be more useful for this purpose?
I am more concerned for the Integration Test part as i've mentioned above. I'm looking for anything in LAMP/Axkit/Perl related method.

Thanks.

I think you'd fix the bug initially and then the regression tests would be composed of TDD.

Kezzer 2009-01-21 09:58:38

mm, i thought you're supposed to write test before code? Doesn't this setup is in kind of reverse? thanks.

melaos 2009-01-21 10:00:52

I'd tend to agree. I'm actually reading a book on TDD at the moment so I'm only just getting into it. I guess your bugfix should concentrate on TDD also before you even implement it. Good spot.

Kezzer 2009-01-21 10:04:45

Yeah, you may be able to fix the bug incidentally. But it is good practice to write the test before fixing the bug. Or else you won't know for sure if you have working regression tests at all.

Spoike 2009-01-21 10:35:51

At least you'll be sure to pass the regression suite. Sort of like doing the design after cutting the code, it's a perfect match :-).

paxdiablo 2009-01-21 10:47:10

+7 A:

When a tester finds a bug I usually write a unit test for it. When the test succeeds, I know the bug is fixed and it will always be covered again in the future.

Gerrie Schenck 2009-01-21 10:02:54

do u do the unit test for Integration test too? or you one of the lucky ones to already have all those done for you? :) thanks

melaos 2009-01-21 10:04:16

You're right, this involves mostly writing integration tests instead of unit tests.

Gerrie Schenck 2009-01-21 10:11:52

@Gerrie, so basically you're just writing unit tests to test feature/behavior that is already there right? Argh, i wish i could steal enough time to do that to some of our existing stuff. All codes and no tests :'(

melaos 2009-01-21 12:57:37

+1 A:

I always wrote tests before the actual code while fixing a bug.

This way I had the example of what to expect from a working code - and I could just focus on making this test (and all others, for regression) pass.

kender 2009-01-21 10:03:52

+21 A:

Write a test that fails because of the bug.
Fix the bug in your code.
Re-run test.
Re-run all tests.

So - yes - very much so.

DanSingerman 2009-01-21 10:03:57

5. Add that test to the "all tests" suite for next time. This expands test case coverage.

paxdiablo 2009-01-21 10:48:09

I hoped that would be inferred. I'll add it if anyone else thinks it's not obvious.

DanSingerman 2009-01-21 10:50:29

Add: 5. ??? 6. PROFIT! You get my vote.

strager 2009-01-22 02:25:27

Oh well, no-one else thought it wasn't obvious. Must be just me that's thick :-).

paxdiablo 2009-01-22 02:25:37

+3 A:

The answer in short is yes. The basic structure of doing that is to write a test case which would simulate the bug and fail the test case. Then fix the bug which would pass the test case.

Santosh S 2009-01-21 10:05:08

+6 A:

When you have a bug in your system it is good practice in TDD to write a test that spots the bug (i.e. a red test that proves the bug). When you have to fix the bug, the test should eventually turn green. It may be a good idea to ferret out any other bugs if they're close enough.

Regarding debugging, TDD should be used to leverage debugging sessions away from the programmer. You can still debug, if you have no idea where some bug is, but it's easier to pinpoint a bug if you have a regression test suite with enough granularity.

You have to remember though that TDD is more about unit testing and not about integration testing. There is nothing wrong with writing integration tests since they're a sanity check to make sure your application or system under test works.

One book that is about testing with xUnit frameworks is the xUnit Patterns book that is general enough to work with any unit testing framework (even for PerlUnit I would guess) a cookbook of interesting tricks you can do with xUnit frameworks.

UPDATE: There is a chapter about unit testing in perl at Extreme Perl.

Spoike 2009-01-21 10:08:10

it's the equivalent to Test::More in Perl? thanks.

melaos 2009-01-21 10:10:55

melaos: I quickly checked out Test::More http://perldoc.perl.org/Test/More.html, it seems similar. Assertions are there with the ok(...), is(...), isnt(...), like(...) and the other lot.

Spoike 2009-01-21 10:32:15

melaos 2009-01-21 12:56:26

+2 A:

Yes. Of course all the tests you performed during TDD of your release will have been added to a regression test suite. But, in the case of a bug, that regression suite obviously wasn't detailed enough.

The first step in fixing a bug is replicating it and this is TDD. Once you find a test case that replicates the bug, you can expand on it if you wish (to catch other obvious problems of the same class), but I don't tend to do a lot of expansion since we have specific turnaround times for fixing a single bug.

Once you have a fix for that bug, add the test case to the regression suite. The idea is to keep adding test cases to the regression suite for both releases and bug fixes to give it very good coverage.

paxdiablo 2009-01-21 10:11:45

it's one of the problems i'm facing as i don't have any regression suite. and i'm just beginning to pickup TDD :)

melaos 2009-01-21 10:16:27

I think the lack of a regression suite is a different issue to whether you should use TDD for bug fixes. Maybe start a separate question along the lines of "How do I start using TDD on an existing application?"

DanSingerman 2009-01-21 10:27:01

You don't have to go the big bang approach for a regression suite. You *should* have some form of automated testing to which you can add tests to gradually. Even if you only add one per bug fixed, at least that's better than nothing and that bug won't manifest itself again without you catching it.

paxdiablo 2009-01-21 10:45:48

@HermanD: thanks maybe after i build up some understanding i will ask that question again. @Pax: yea, that's what i thought, it has to start somewhere. thanks guys.

melaos 2009-01-21 12:55:01

+1 A:

Yes but beware, If you write as many bugs as I do you will soon have a huge set of tests to cover all the bugs you have written and then fixed.

This will mean tests runs will be slower, and intent of behaviour will become muddied by your bug tests.

You could keep these tests logically separate or revisit your original set of specified behaviour checks (read tests) to see if you really have covered all your expected behaviour.

I think its important to differentiate between the two.

John Nolan 2009-01-21 10:47:51

ansaurus

tags:

views:

answers:

Do you TDD for debugging fix?

related questions