Since my last post I have tried using VS2005's testing framework and NUnit with our actual code base. Yesterday I checked in the first tests (totalling 38 test methods for a single class) to our source code control. I had picked the class under test quite randomly but hit a sweet spot with my choice - one of the tests found a bug in a method that was written more than three years ago. And I actually tried to write the tests to match existing code... Perhaps the method is not used very much, since no one had noticed the bug before. (It should have turned up by now, because the method generates a short part of an SQL statement, and with one valid input it returned SQL that is not valid in any DBMS.) There was also at least one method where a null parameter was not considered a special case.
"The other guy" tried checking out the tests and running them, and everything went smoothly. He also thought the tests were a good example of finding small bugs in existing code. Since everything had worked, I updated my paper and added some technical details about running the tests.
Today I finished writing it (at 19 pages) and checked it in. I also wrote tests for another of our basic classes and checked them in as well. This time writing 24 test methods took a lot less time than the previous ones.
So far no one has commented on the work - except for the guy who wrote the method with the bug I found. I went to check if it was ok that I used his method as an example of hard-to-see bugs that could be found easily with testing. He was just browsing through my paper and was pretty impressed. Although no one else has given any feedback, I feel pretty confident. I actually think I'm changing things here.
Let's see if I'm just fooling myself or if my colleagues also start writing some tests.
2 comments:
Good luck :) I am under the impression that maybe an easier approach to start bringing TDD or any kind of programmer testing to an environment would be to start doing new features and/or bug fixes with TDD. But anyway all this is so contextual that it's better to not rely on any single silver bullet.
With bug fixes it's particularly straight forward. When you start to fix a bug, you try to create a test that would fail because of the bug in a way that demonstrates the bug (i.e. the test that would have saved you from the bug, and which will hopefully tell you when the fix is ready). And when you have the test failing in the way you want, you go ahead and fix the bug and expect the test to pass.
Thank you for the input.
I also think that would have been better, but currently I'm not assigned any bug fixes in our C# development. I tried to introduce TDD by talking with a couple of people but they wanted to see if the tests could actually be done in our environment. So, I kind of had to start with existing code.
However, I wrote two or three paragraphs about the basics of TDD to the paper I wrote. I mentioned that I believe it would take some time to adopt such practice in our company, but I also wrote the exact things you mention about doing bug fixes with TDD. I also wrote how I think TDD is quite intuitive, since programming is often about problem solving and TDD gives you one very small problem at a time to solve.
I left out the "Besides, TDD is fun!" part, although I think it's also true. :)
Post a Comment