This is one of the most useless unit tests I’ve encountered
/// <summary>
///A test for GetByLegalCaseID (int)
///</summary>
[TestMethod()] public void GetTicketByLegalCaseID_Test() {
TicketEntityModel target = new TicketEntityModel();
int ID = 1;
TicketDataSet actual = target.GetByLegalCaseID(ID); Assert.IsNotNull(actual, "TicketDataSet was not returned.");
Assert.IsNotNull(actual.Citation, "No Citation table was returned.");
Assert.IsTrue(actual.Citation.Rows.Count > 0, "No Citation rows were returned.");
Assert.IsNotNull(actual.Ticket, "No Ticket table was returned.");
Assert.IsTrue(actual.Ticket.Rows.Count > 0, "No Ticket rows were returned.");
} |
Unit tests in the Entity Model should concentrate on testing business logic, not Data Access Layer (DAL) logic. Unit tests for DAL objects test data access issues. Furthermore, this Unit Test simply checks to see if the current database has a record with an ID of 1 and, therefore, is non-deterministic. It can fail for many reasons that have nothing to do with the business logic. If GetByLegalCaseID has any business logic in it then unit tests should to be written to test that logic and the dependencies on the DAL would be mocked so a previously setup DataSet is returned with known values. This falls under the “What Burns Me” category.
5 users responded in this post
OMG!!!
I could think of some problems such a useless unit test would help to detect, having been bitten by one just a few days ago. Somebody mistakenly renamed a stored proc in DAL. No big deal, but the problem went undetected for a while.
I would be OK with these unit tests if they were generated – many orm generators (nettiers for one) generate unit tests for the DAL.
But, given that the DAL is often a moving target I wouldn’t want to manually create and update these unit tests. It’s more trouble than it’s worth. Your time would be better spent unit testing the business logic.
I would argue this is an Integration Test, not a Unit Test. Hope I didn’t write it!
This unit test should be testing the DAL based of the code shown. What you are describing "testing business logic" should be a separate unit test. This unit test has many advantages such as testing the SQL or Stored Procedure that were associated with this call, Verifying that the code can still reach the server, Verifying the code still has permissions to preform the action in question, etc…
The business logic code isn’t suppose to sit in the DAL so this test by nature doesn’t focus on business logic. If you search around there is probably another test somewhere that test against business logic and leaves the DAL out of the equation.
Leave A Reply