Turn Databases Into APIs for Data-Driven Testing

The most effective method of testing an API program involves creating multi-step integration tests that validate common API consumer flows. API endpoints are meant to work together, so it follows that test data coming from one API that feeds another API should not be fixed or pre-built. This is very important because the less you rely on fixed data, the more unpredictable and therefore thorough the testing path will be.

Moreover, API mutation operations may have side effects that cannot be evaluated by simply validating the same endpoint. Side effects propagate throughout the system, and their efficacy can only be validated by querying other endpoints and comparing the results.

Deploying and Reverting Clones for Database Development and Testing

SQL Clone is a very handy device for database developers. The main thing stopping me from initially using it more widely was culture shock. It is a new and strange experience to be able to have several local copies of the database I'm developing without worrying about disk space and without having to fuss about keeping them up to date. This means that I can create a series of cloned databases and then migrate each one to a different version without requiring enormous amounts of storage.

Even more of a shock is being able to make radical changes to the data or schema while testing in the knowledge that it takes only a few seconds to revert the database back to its original state, ready for the next test run. I'll show how to use SQL Clone, the database provisioning component of SQL Provision, to achieve all this. With a bit of additional scripting, you can even revert a copy of the database without worrying too much about losing any schema changes by using SQL Compare to compare the altered database with an unadulterated clone and save any changes as scripts in files.