Unit tests are often deployed with software releases to validate the install – i.e. do the install, run the tests and if they pass then the install is good.
I’m about to embark on a project that will involve delivering prototype software library releases to customers. The unit tests will be delivered as part of each release and in addition to using the tests to validate the install, I plan on using the unit tests that test the API as a ‘contract’ for how the release should be used. If the user uses the release in a similar manner to how it is used by the unit tests then great. If they use it some other way then all bets are off.
Has anybody tried this before? Any thoughts on whether this is a good/bad idea?
Edit: To highlight a good point raised by ChrisA and Dan in replies below, the ‘unit tests that test the API’ are better called the integration tests and their intent is to exercise the API and the software to demonstrate the functionality of the software from a customer perspective.
Sounds like a good idea to me. I (we all?) routinely use unit tests internally to do just that. In using my unit tests to validate that I haven’t broken anything I’m also implicitly verifying that my API contract hasn’t changed. It seems like a natural usage of unit tests to deploy them in the fashion you’re talking about.