This project is read-only.

FAQ

Topics: User Forum
Dec 30, 2006 at 8:00 PM
FAQ
1. What are some good links to testing?
2. Does the MassDataHandler work only with MSTest?
3. Why would you ever have logic in the data layer, that's bad architecture?
4. Why do you call it a "Database" Unit Test when that's contradictory - if something is testing the database, it's no longer just a unit test?
5. Why not just use mock objects?

--------

1. What are some good links to testing?

* http://www.pragmaticprogrammer.com - A practical site about agile processes and coding better.
* http://www.testdriven.com - A site "dedicated to promoting techniques, tools, and general good will in the test-driven community."
* http://jimshore.textdriven.com - A great agile advocate.
* http://weblogs.asp.net/rosherove - An MVP who frequently writes about agile methods
* http://aspnet.4guysfromrolla.com/articles/040605-1.aspx - An older article that discussed concepts for testing the data layer.
* http://www.codeproject.com/csharp/autp1.asp - A introductory tutorial to unit tests.

--------

2. Does the MassDataHandler work only with MSTest?

No - it is simply a .Net 2.0 binary, and can be consumed by any .Net code - including NUnit or even your own custom code.

--------

3. Why would you ever have logic in the data layer, that's bad architecture?

Ideally all logic would be in easily-tested managed code, but the world isn't ideal. There are legitimate reasons that logic may be in the data-layer:
* Performance - certain complicated core stored procs (like for security), that aggregate tons of tables, may need to reside on the database for pure performance reasons.
* Complex filters - often the filtering logic resides in the stored proc because you don't want to pull all 10 million rows back to the app server.
* Legacy code - certain projects already have years of code in the stored procs, and the team culture may want to keep it that way.
That an entire language (T-SQL) exists to program database objects tells you that there are reasons to have logic in the database - a language wouldn't exist unless there was a need for it.
There are lots of ways to abstract logic out of the data tier and decouple your tests from the database (better design, mocks, ADO.Net transactions, embedded CLR functions in SQL 2005, etc...), but sometimes you're just going to be stuck with logic in the datalayer, and during those times, it's nice to have a tool to help test things.

--------

4. Why do you call it a "Database" Unit Test when that's contradictory - if something is testing the database, it's no longer just a unit test?

There will always be some purists who insist that testing a database is contradictory to the very definition of a unit test - and anyone who doesn't grasp that just doesn't "get it". We think this view is too extreme. We fully agree that ideally a unit test should only check a single thing, and hitting a database requires multiple things (connect, insert data, run object, get data, etc..), therefore a database test is beyond the scope of a "pure" unit test. However, semantics aside, there can be legitimate logic in the data layer and it adds value to be able to test that logic. A simple Google search shows millions of results of people trying to unit test the database. We refer to the MassDataHandler helping with "Database" Unit Tests because:

They meet the main requirements of unit tests (Pragmatic Unit Testing in C# with NUnit by Andrew Hunt and David Thomas)
* Automatic - Run using any automatic testing framework you want.
* Thorough - By setting all the individual data that a test needs, you can test specific logic with as much detail required.
* Repeatable - Can run multiple times with the same result.
* Independent - This is the biggest problem, but it still works well enough. First, each test does run independent of each other by creating its own data (as opposed to some solutions which require inter-related tests to run in a certain order, or install base data shared by all tests). Given the steps in a database test, everything else should be reliable enough such that only the database logic is really being tested. (1) Set up schema - (taken for granted, therefore not tested) (2) Connect to the database - (taken for granted, therefore not tested)(3) Populate the test data - (MDH makes this so reliable that it's not likely to fail, therefore taken for granted, therefore not tested)(4) Collect input parameters to call the data object, done with auto-generated code (taken for granted, therefore not tested) (5) Run the database object - this is the thing you are actually testing.(6) Generate a managed code object to store the data results (usually code-generated, therefore taken for granted, therefore not tested) (7) Perform assertions.
* Professional - They always pass, are quick, and are easily maintainable by others.

They are run alongside all the other unit tests in a framework like MSTest.
They are differentiated from "pure" unit tests:
Developers can distinguish them with a database category in their test suites.
We don't just call them "unit tests", but rather "database unit tests", so that we think of them with a clear distinction.
They are not trying to ensure that your database connectivity works - that's taken for granted. (But the test will fail if there's no connectivity).

The goal of the MassDataHandler isn't to change your semantics or buzzwords, but rather add value by letting you test logic that resides in the database. Whether you call this a "database unit test", "integration test", "functional test", "xyz test", or "you-have-bad architecture-if-there's-logic-in-the-database test" is your choice.

--------

5. Why not just use mock objects?

Mock objects are great for mocking-out the database, but there are times when there is legitimate logic in the database and you want to test that logic. In these cases, mock objects don't solve the problem.