THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Alexander Kuznetsov

Benefit from Unit Testing T-SQL: Speed up Maintenance of Unit Tests Part Two

In this post we shall see how adding test data breaks existing unit tests, and how to fix them.

This post continues the series on unit testing, the previous posts are

How to Benefit from Unit Testing T-SQL: choosing what not to test

How to Benefit from Unit Testing T-SQL: choosing what to test

How to Benefit from Unit Testing T-SQL. Part One.

How to Benefit from Unit Testing T-SQL: Reusing Manual Tests as Parts of Unit Tests

How to Benefit from Unit Testing T-SQL: Exposing Failure in a User-Friendly Way

Benefit from Unit Testing T-SQL: Reuse Unit Tests as Documentation

Benefit from Unit Testing T-SQL: Speed up Your Test Harness


When changing test data breaks some tests

Suppose that we need to test another stored procedure, which returns total amount of messages sent, grouped by user, month, and year. Typically we prefer to reuse existing test data as much as possible. However, to test this module we need messages sent on different months, so we need to add more messages sent by the same user on another month.

When we do that, these additional rows may show up in the output of the existing stored procedure, which may break some unit tests . To accommodate for that, let us regenerate expected results, and visually confirm the changes:



Typically it is much easier to reuse the same test data and adjust expected results as needed, than to come up with separate test data for each test.
Published Wednesday, October 27, 2010 5:32 PM by Alexander Kuznetsov

Attachment(s): adding_row.JPG

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS


No Comments

Leave a Comment


About Alexander Kuznetsov

Alex Kuznetsov has been working with object oriented languages, mostly C# and C++, as well as with databases for more than a decade. He has worked with Sybase, SQL Server, Oracle and DB2. He regularly blogs on, mostly about database unit testing, defensive programming, and query optimization. Alex has written a book entitled "Defensive Database Programming with Transact-SQL" and several articles on and Currently he works as an agile developer.

This Blog


Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement