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.