Haroon Ashraf walks us through a simplified example of test-driven database development:
In TDDD, business requirements are encapsulated in database unit tests.
In case the requirement is adding a new category to the Category table, it is necessary to implement TDDD according to the following steps:
-
Creating of database unit test to check the existence of AddNewCategory database object.
-
Failing of the unit test because of the database object absence.
-
Creating the AddNewCategory object in order for the unit test to pass.
-
The unit test determines whether AddNewCategory stored procedure is actually adding a new category or not.
-
That unit test also fails.
-
AddNewCategory procedure code changes to add a new category that verifies afterrerunning the unit test, which is able to pass now.
Laying out my biases, I’m not a fan of TDD for application development and definitely not a fan of it for database development. “Unit testing” inside a database is extremely limited, particularly when there are so many side effects and encapsulation tends to be actively harmful.