September 24, 2019 at 12:00 am
Comments posted to this topic are about the item Using tsqlt Tests to Practice Queries
September 24, 2019 at 7:54 am
To anyone who says "Why write tests?" I'd say the tests should capture desired system behaviour and those desired behaviours are a technical expression the business requirements of what was built.
While systems are developed the team building those systems know what they are doing, what they are working towards etc. Unless the team owns that system in perpetuity and also has a low staff turnover that knowledge quickly evaporates. Those tests inform the inheritors of the system as to what it is supposed to do and whether it is doing it.
There is another element to mechanical testing. You can't argue with a computer. Strength of personality or passionate belief does not factor into it.
I've worked with testers who are much happier in a preventative role rather than in a more traditional testers role where timescales compress what can be tested and what can be fixed. Helping to define the tests upfront is much more satisfying and leads to a better quality product.
Will it catch all bugs? No! But every time a new bug is discovered it is an opportunity to introduce a test that would have spotted it. Sometimes working out how a situation could have been tested is more challenging/interesting than the actual functionality itself.
Jo Hannaford (Global Head of Quality Assurance Engineering at Goldman Sachs) gave an interesting definition of legacy code. A legacy system is when the code is too complex to change or when lack of knowledge makes developers too scared to change the code. Tests address this is two ways
September 24, 2019 at 12:02 pm
Thanks for the straight-forward example, Steve. Things like this show that tSQLt testing isn't difficult and helps you avoid deploying bugs in the first place.
We adopted tSQLt for database unit testing as a formal standard over 4 years ago. The startup was a little difficult as with all mindset changes but we kept at it. We have developed an internal schema to augment the base tSQLt package to generate simple tests (schema and constraint, for example) and to release SCHEMABINDING. While some parts are code generators we also have an overload of FakeTable to incorporate our local enhancements.
We find that, many times, we are the first exposure new developers have with tSQLt specifically and database unit testing in general. I'm not sure what that says about how, as an industry, we are training our developers.
Calling a stored procedure instead of embedding the code certainly makes for easier maintenance. I think the larger benefit is training developers to think in terms of black boxes. Then the test scenario deals with input and expected output without the test knowing the how.
Unfortunately a robust unit test infrastructure and skillset does not keep developers from writing EF, effectively embedding code, giving other layers intimate knowledge of the data layer instead of operating on contracts, and creating code where part of it is never unit tested, only integration tested. Given the source of the unit testing mantra (which was NOT database people), you'd think that testability and reduced coupling would be enticing arguments.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
September 24, 2019 at 6:22 pm
That was really the idea here, to get people thinking of how to test scenarios. I think this is more powerful an argument than a general introduction to testing. I plan on doing more of these, but if some of you find good test areas that you've found useful, would love to see similar short articles on testing a type of query submitted.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply