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.