Wednesday, June 23, 2010

Automated Testing Frameworks

A good friend of mine asked me today, how many test harnesses, or automated testing frameworks I've either written, or participated in the creation of now. Honestly, I had never really stopped to think about it, but it's been more than a few. I've had a lot of people suggest over the years that it shouldn't be necessary to start over and create a new one, when there are lots of good ones already out there. There's some common sense in that, however in reality it doesn't necessarily work out that way.

The question "How many testing frameworks have you built?", to me, seems a bit like asking "how many different pairs of shoes have you worn?" I'm not big on shoes or anything, but I do have different ones for different purposes. I have tennis shoes that I typically wear, dress shoes for church or other occasions where sneakers would be too informal, and motorcycle boots. They each have a very different purpose, and for the most part, need to be completely different. Sure, in theory someone could design a dressy, tough, boot that's comfortable to run in. I'll give you a second to try to picture that... Ok, I think you get my point now.

Testing frameworks are kinda like that too. They are often built with a specific purpose in mind, because the existing solutions don't quite do what they wanted, or don't do it in a way that they like. So, rather than try to force themselves upon an existing project, which was created with different goals in mind, developers often start over. This allows both projects the freedom to explore what they want to do, in the way they want to do it, without interfering with one another. Some would call this fragmentation, but I look at it as specialization with opportunities later for collaboration where it makes sense to do so!