I do like to spend time to design better early on and do various tests to confirm i am on the right track.
And doing so by making mini-scripts and specific test scenario's with sparse commenting.
Once I know the design and solution works, it works and that concludes the lifespan of the tests.
When something changes that affects implementation, it also affects design and design decisions...making formal tests obsolete in most non-trival situations.
While I understand the safety feeling tests can bring, I also wonder why few recognize that the person writing the tests is the same person that does the implementation and often even the overall modelling and design.
This means tests are an extra layer of code that can go wrong, while not really challenging the design properly.
Flaws in thinking about the design, in the implementation or in coding the tests are essentially the same.
Tests can only prove that ** when ** the developer works precise, the implementation does what the developer thinks it should do (which changes as soon the system gets modified).
In my eyes working precise and being assertive is what counts.
The idea that creating formal tests as a way of working, somehow magically brings that...I do not see that with myself, nor do I see it with others.
The amount of 'code' in a database should be pretty limited, most of the guarantees should be inherent in the modelling (normalization and constraints).