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.
Tuesday, August 15, 2006
Friday, August 04, 2006
Winds of Change
Last week I wrote how I had planned to start talking with my colleagues about improving our processes much more than I had did before. That's exactly what I did.
First, I talked with one of the guys in our internal IT support. He totally agreed with me that we should not be doing things manually if they could be automated. He also told me that one of the developers had tried "some XP thingies" earlier, so I went to have a chat with him. He had read something about unit testing but had not done any on his own. I promised him I'd try writing some tests for some of the most used classes in our production code. He was willing to help, if I needed anything.
Then came the development discussion. I told my superior about automated tests and builds, and she gave me a go-ahead to try and write some tests. I installed Visual Studio 2005 that same day and have tried writing some unit tests with the built-in testing framework. So far I've just been playing around but I still feel great. I also wrote an 8-page paper about unit testing, including instructions for getting the framework to work properly. To be honest, the paper ended up having some propaganda-like raving about the importance of testing and proper coding style. It was still received well by the other guy interested in XP, who is the only one who has read it so far. We also thought I might install NUnit and try it out for comparison. Now I'm getting some other work done, but next week it's time to dive into writing those actual tests.
The only issue I'm worried about is our company culture. All the people I have spoken with have been somewhat intrigued by my Agile ranting but have also questioned whether it's possible to change the way people here work - and have worked for over ten years. That's a challenge, and I must try and point out some benefits from writing tests for our code. I'm also curious to see whether our code is actually so well written that it will be fairly easy to write those tests.
As a side note: I even started thinking whether tests could be used to "guard" good coding standards. For example, making sure methods don't change their parameters' state as a side effect could usually be tested quite easily. Then again, including such checks in all unit tests would probably make the test code bloated and tangled. Still, even if people agree with me that such side effects are unwanted, they might have a hard time adapting to a new coding standard that differs from the way they have written code for years now.
Well, I guess (and sincerely hope) I won't find that many serious code smells when digging through the code base.
First, I talked with one of the guys in our internal IT support. He totally agreed with me that we should not be doing things manually if they could be automated. He also told me that one of the developers had tried "some XP thingies" earlier, so I went to have a chat with him. He had read something about unit testing but had not done any on his own. I promised him I'd try writing some tests for some of the most used classes in our production code. He was willing to help, if I needed anything.
Then came the development discussion. I told my superior about automated tests and builds, and she gave me a go-ahead to try and write some tests. I installed Visual Studio 2005 that same day and have tried writing some unit tests with the built-in testing framework. So far I've just been playing around but I still feel great. I also wrote an 8-page paper about unit testing, including instructions for getting the framework to work properly. To be honest, the paper ended up having some propaganda-like raving about the importance of testing and proper coding style. It was still received well by the other guy interested in XP, who is the only one who has read it so far. We also thought I might install NUnit and try it out for comparison. Now I'm getting some other work done, but next week it's time to dive into writing those actual tests.
The only issue I'm worried about is our company culture. All the people I have spoken with have been somewhat intrigued by my Agile ranting but have also questioned whether it's possible to change the way people here work - and have worked for over ten years. That's a challenge, and I must try and point out some benefits from writing tests for our code. I'm also curious to see whether our code is actually so well written that it will be fairly easy to write those tests.
As a side note: I even started thinking whether tests could be used to "guard" good coding standards. For example, making sure methods don't change their parameters' state as a side effect could usually be tested quite easily. Then again, including such checks in all unit tests would probably make the test code bloated and tangled. Still, even if people agree with me that such side effects are unwanted, they might have a hard time adapting to a new coding standard that differs from the way they have written code for years now.
Well, I guess (and sincerely hope) I won't find that many serious code smells when digging through the code base.
Subscribe to:
Posts (Atom)