You have someone else’s code. You have to use it. To use it you have to learn it. If the code had automated unit tests you could read the unit tests to see how the code behaves. But, it probably does not have unit tests. So, you read the documentation. The documentation usually leaves some room for interpretation in the best case. It lies and misleads in the worst case. What do you do? You read the code.

Reading the code. What fun. it’s especially fun in the function call, data structure, free for all know as C. When I read code I start to build a model and vision of what this code does. This vision is built up in the short term cache between my ears.

The the phone rings or my wife comes by and it happens. My short term cache is cleared. I get to start over. Great! There must be a better way. I’ve got it! Commit the short term cache to a longer term form of knowledge storage. Automated unit tests are great at capturing what the code does. They are an executable specification of the code’s behavior.

When we hunt through code to figure out how it works, we have these ahah! moments. Don’t be satisfied that you are right, or that you will remember this newly discovered bit of information. Capture what you learn in unit tests, committing the knowledge to a reliable form of long term memory.

When you write a learning test sometimes you find that you are right and the code does what you expected. Other times you are way off. But now you know. There is no more guess work. The tests solidify the learning. You had a hunch, but after the test you have corroborating evidence.

It sounds like a lot of work. But you have to do the work to learn anyway, and if you don’t capture some of what you have learned in code you are bound to have to relearn it again later.

Oh, yeah. remember you are using someone else’s code. What about when they change that code. Will you upgrade to the latest? Or will you be too afraid? Fear is natural and prudent in this case. What version compiler are you using? But letting the code get behind reduces the value of including that code in the first place because now you must maintain it.

If you had the the learning tests, and they reflected how you used the third party code, you can compile and run the the tests against new releases. Test failures tell you that you have compatibility problems. Yeah but… that sounds like too much work, writing all those tests.

If you did not have the tests you would now have a bug! So what! Finding the incompatibility when it manifests itself as a bug is no problem. Reading the release notes will keep you from having a bug. But now I am being sarcastic. Back to straight talk.

I think learning tests are free, or better yet have a high return on investment. They are almost free while you are doing the learning, and they payback plenty when they find those compatibility problems. In addition if they help you avoid adopting the maintenance responsibility of the third party code you and you can accept new releases there is even a bigger payback.

So I say flush the short term cache between your ears regularly into automated tests.