November 11, 2011

...Learn TDD with Codemanship

Check Backwards Compatibility Using Versioned Tests

Here's a quick tip, inspired by a tweet from @hotgazpacho, who was venting his frustration at .NET developers who didn't seem to have grasped the issue of component version compatibility.

I think it was a comment on a vendor's web site about "maintaining compatibility" of a new version of one of their libraries with old client code by freezing the component's version number that set him off.

He's quite right, of course. Can I let you in on a little secret? Those assembly version numbers? They don't mean anything, really. They're like license plates on cars. You can take the license plate off your old car and put it on your new car, but that doesn't mean they'll perform the same.

If you really want to know if the latest version of your component is compatible with existing client code, here's how we used to do it...

You write a suite of tests against the public interfaces of your component. These tests will no doubt evolve as your component evolves, but it is entirely possible to version your tests, too. So each release of your component gets a corresponding test suite. If you want to know if version N+1 of the component wuill be compatible with verion N client code, run the version N tests against the N+1 release.

That way, you can check whether N+1 fulfils the contracts of N. And that's what we mean by "backwards compatibility".

Posted 9 years, 3 months ago on November 11, 2011