[Study Note] Design and Testability 20100412

[Unit Testing Business Logic without Tripping Over the Database]

reasons to avoid data access calls inside unit tests for the business logic

1. Tests with database calls will execute significantly slower than tests that stay within an AppDomain.
2. Tests with database calls are more labor intensive to write.
3. Damned if you do, damned if you don’t. … make the tests harder to read and understand
4. The intent of the unit tests can be unclear.

Mock the Database, but Where?

One of the best ways to get the database out of your way is to hide data access behinde abstracted interfaces that can be mocked in business logic testing.

Do not mock happy, fun ADO.Net.

a business or even service layer class should never have any reference to any of the System.Data.* namespace.

No Business Logic in Stored Procedures!