Gary Varga (7/25/2016)
Chris Harshman (7/25/2016)
Where I work, the developers do a lot of test driven development for their C# work, but a limiting factor for them doing more on the database side is the tools available. They evaluated some methods, and tried tSQLt for a while, but had more problems with it than problems that it solved.For me, this is the issue.
The same could be said of UIs too. It has always been simplest to test code without a complex system to interact with (humans, databases, hardware, etc.) and that is why we stub, mock and simulate these complexities.
Much work has been done to improve UI testing in recent years (particularly in the JavaScript/HTML world), however, for me SQL Server is lacking vendor support for testing. There needs to be a way to inject something between stored procedures and the data, for example.
I think the problem my company had on the database side was that the data is highly context sensitive, so testing the same data or the same operations at different points in time would expect different results. In the UIs I've seen a number of times where the developers changed the name of a control or moved something on a form and it caused the smoke test the QA department did to get confused. Usually they remember to inform QA so they can update the smoke test setup, but there isn't a easy way to automate detecting those changes.