Test Driven Development, or TDD, means we start with unit tests, even before writing our code. When done properly, TDD leads to higher quality systems. It gives us good test coverage, it's automated and it gives us good regression testing.

To isolate the unit tests, so that they only verify the behaviour of an invidiual method or function, everything outside of the function is mocked. This is a really good idea. If we write a function ConvertCurrency and that function calls service GetCurrencyRate(date,currency), create a mock service which always returns the same value.

How about unit tests for the service GetCurrencyRate? The service probably gets the currency rate for a certain date/currency combination from a database, perhaps through the stored procedure call Finance.GetCurrencyRate. And just like the unit tests for ConvertCurrency uses a mock service for GetCurrencyRate, the unit test for GetCurrencyRate will use a mock for the stored procedure Finance.GetCurrencyRate.

But who will test the stored procedure Finance.GetCurrencyRate?

In this session we will talk about test driven database development. How we can apply the TDD methodology to database development. We will look at the most common unit testing frameworks and how they integrate with database development environments. We will look at unit test design and how we can isolate unit tests to only test the logic of an individual statement, view, stored procedure or user defined function.