Monday, February 18, 2008

Testing on an island

I read Derek Whittaker's post the Sound of One Man Testing, and it got me thinking to the first to adopt people. The ones that read incessantly and find the hints of good ideas and do what they can to introduce new concepts into their work. These people are the ones that figure things out, and solve the hardest problems, they go the extra mile all the time.

I got to thinking about unit testing at my own work. About 3 years ago I had just heard the concept of test driven development. The few paragraphs I read about it sounded interesting, but I couldn't quite get my head around it. I didn't understand why I'd write a test for every level of code, when an integration test would take care of all of it. This just didn't make sense to me. I like to pride myself on being one of those early adopters. I'm not on the bleeding edge, but I do what I can to read about things and stay up to date at least on the concepts for things. Test Driven Development is a huge concept, with great benefits and I couldn't quite get it. It took me a reading a couple of books and writing a project with test driven development before I started to get it. Yes, after a fully TDD project I only started to get it. Even at that point I had done things wrong. Mocks were still a mystery and I hadn't found any good tutorials. For the first time I felt like I needed my hand held as I walked through something new. It was scary.

When it comes to work I tend to be fearless and take on any challenge given to me. But this was different. So for those early adopters that are out there trying to be the person testing on an island and starting it in your company. Remember, even for some of those who tend to lead, it can be hard. If you work in a place where you do have some small 1 man projects I recommend using one or two of those as proof of concepts for TDD before even attempting to insert it into a larger project. Talk to your co-workers about TDD. Send them blogs, magazine articles, books, anything to make TDD a topic of conversation. And then, offer to hold their hand. Show them with in-house training, led by you. Teach them about mocks and dependency injection and why you have to use them with the design in order for the unit tests to be black box. Explain black box and talk about all of these concepts, which are very likely new concepts to a team that is not already doing Test Driven Development.

Finally, start adding tests to a large project that you are working on. Offer to help your co-workers build their tests.

I've been reading about TDD for 3 years now. Currently I'm working in Java and I'm comfortable from the bottom layer all the way through the web service layer in writing tests, but I still don't know how to test the GUI. Even after 3 years there is still a lot of room to grow in my Test Driven development. And if you are thinking of starting Test Driven Development, don't look at this and think that it's too hard. It's not, and the quality that you gain in the layers that are tested is great. The current project I'm working on is closing in on 1,000 unit tests. I love being able to run them and know that the refactoring that I had just done didn't break any code that someone else was relying on.

1 comment:

John said...

Cool article, I agree with the points you brought up.

You mentioned not knowing how to test a GUI. I code asp.net apps, and for me the MVP pattern works really great for separating concerns. The article that turned the key for me was the MVP article in the June 2007 issue of Aspnet Pro (I believe the article's available on line)