One of the most valuable lessons I’ve learned in performance tuning is the importance of breaking queries tasks into smaller, more manageable sections. Who knew? The experts were right all along when they said, “If you’re confused by the query, SQL probably is too”.
Welcome back friends!
During the past four posts, we have covered the fundamental concepts regarding tSQLt, look at how far we’ve come!. So far, everything we have done has been within SSMS using the open source framework that is tSQLt. In this post, we’re going to take a look at some third party tooling available, harnessing the power of tSQLt.
We’re back once again, with another instalment of the tSQLt series. I hope you’ve been enjoying it so far. Personally, I’ve had a blast getting back into this topic. In the last post, we covered one of the many useful features of tSQLt, the Fake Function option.
Taking this further, in today’s post, I want to cover the Spy Procedure option.
The Journey Continues!
Welcome back to the tSQLt series, where we are covering the fundamentals of Unit Testing within SQL Server by using the tSQLt Framework.
Today we’re progressing onward by discussing some of the useful features within tSQLt to ensure our tests are accurate, reliable, and repeatable.
Unit Testing Experts!
In the last post, we went through what unit testing is, at least when discussing it in the context of SQL Server. In addition to that, we discussed what benefits using the open-source framework tSQLt can bring. Of course, you have studied that post diligently and now we’re all unit testing experts, right? … hello?
Unit…what now?
Other practitioners of code-slinging, such as .NET folks, have been unit testing their code for many moons now. We SQL folks, however, rarely seem to do this, at least in my experience. Several job roles ago, I had to use unit testing on a daily basis. It was heavily integrated into our workflow via the CI/CD pipelines we used
