When I wrote my first tSQLt test in late 2012, unit testing SQL Server stored procedures was enough of a novelty that I had to explain what unit testing was to the DBAs I worked with. That's changed. Four years of using tSQLt across projects has sharpened my thinking on a broader point: tSQLt isn't just a useful tool. It's evidence that data engineering has a software engineering problem — and a model for how to address it.
What Software Engineering Practices Actually Provide
Software engineering practices exist because code is complex and humans make mistakes. Unit tests catch regressions before they reach production. Code review catches problems the original author missed. Source control makes changes auditable and reversible. CI pipelines surface integration problems early. Automated deployment makes releases repeatable instead of hand-crafted and fragile.
These practices were applied to application code decades ago. Data pipelines, stored procedures, ETL packages, and SQL transformations contain the same complexity and the same human fallibility — but for most of that same time period, they were treated as configuration artifacts rather than code. Deployed by hand. Stored in shared folders. Tested by running them in dev and hoping nothing broke. Rolled back by restoring backups.
The consequences follow predictably: fragile pipelines that only the original author understands, production incidents from untested schema changes, ETL jobs that silently produce wrong output for weeks before anyone notices.
What tSQLt Demonstrated
tSQLt demonstrated that the unit testing model works for SQL Server logic — not a modified version, not a workaround, the same red-green-refactor cycle that application developers use. Applied to stored procedures, triggers, functions, views. With the same isolation guarantees, the same assertion model, the same CI integration patterns.
It took an open-source framework to prove this because the tooling vendors weren't treating database code as first-class software. The message tSQLt sent, whether intentionally or not, was: your stored procedure logic deserves the same engineering discipline as your C# class. That is not a radical statement. It took until 2011 for it to become actionable in SQL Server.
The Stack That Now Exists
By 2016, a team can run a complete software-engineering-grade database development workflow using mainstream tools:
- Source control: SSDT database projects in Git. Every table, procedure, view, and function is a versioned file with auditable history.
- Unit testing: tSQLt. Every procedure with branching logic has tests. Tests run in isolation, in transactions, with controlled data.
- Code review: Pull requests on the SSDT project. A stored procedure change gets the same peer review as a C# class change.
- CI: MSBuild + sqlpackage + tSQLt + TeamCity or VSTS. Broken tests block merges. The database tier is a first-class citizen of the build pipeline.
- Deployment: dacpac-based promotion from dev through test to production. Scripted, repeatable, logged — not a DBA manually running scripts from a shared drive at 11pm.
None of these are exotic tools. Git, Visual Studio, VSTS, sqlpackage — mainstream Microsoft stack. The practices are mainstream software engineering. The only thing that was missing for years was the cultural and tooling bridge that made them applicable to database code. tSQLt was part of building that bridge.
The Gap That Remains
Most SQL Server shops still don't do this. The database tier still gets treated differently from the application tier — deployed later in the process, tested less rigorously, version-controlled with less discipline. The tools exist and the practices are proven. The gap is cultural, not technical.
The reason I've been writing about tSQLt for four years isn't that the framework itself is fascinating. It's that the framework is evidence for an argument: data work is software engineering work, and it deserves software engineering discipline. If your team treats the database as an afterthought in the software development process, that's a choice with predictable consequences. The tools to make a different choice have been available since 2011. As always, I'm here to help.