I am working on a project where I needed to delve into a totally new API. To begin with, I needed to take the API for a spin and see what it can do. Starting up a scripting shell was a good start.
However, then I wanted to take it to the next level, so I created test suites which poked and proded around the edges, found the fuzzy areas, and ultimately implemented the ‘user’ features that I needed.
Whenever I do this, I end up with a pretty valuable set of unit tests, as:
- I have a history of playing with the API, that I can go back on to remember why I maybe did something like X
- I have a great resource for how to USE the API. For some reason, a lot of APIs are not well documented, and although you know methods and classes in isolation, it is hard to visualize how they all work together to actually get something done
- I was able to copy this code for the actual implemention of my problem. This just shows even more so how it isn’t a ‘waste of time’, since I used all of it.
The beauty is that over time I have a suite-case full of tests which encapsulate how I played with an API. If I ever need to go back to one of them, I crack open the bad boy, add / modify / play some more…. and borrow code.
If these were cleaned up, they would even make good downloads.
P.S. I often look through the unit tests of projects like Spring to learn more about the API too!
February 18th, 2005 at 2:11 pm
Stuart Halloway talked about it at No Fluff Just Stuff about an year ago. He coined the term “Explorative Testing”. Same idea as you described, write unit tests to build your understanding of an API you are planning on picking up. The tests also serves as a knowledge base that you can get back to in future to see how certain things are done.
February 21st, 2005 at 4:28 pm
Actually I tend to like to poke through unit tests in a project in order to learn how to use it too. The great part about this is that the project committers have already done the work for you.