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.