# Saturday, March 10, 2007
« Reusable IComparer | Main | Reusable IComparer - part 2 »
Testing the test code, not the production code
Right now I'm refactoring an ASP.NET 1.1 application that another team member wrote not too long ago.  When I took it over there were 6 unit tests (4 working ones), but really they weren't true unit tests because the code that went into production was never getting tested.  They weren't really testing anything except for the special case code that only ran when under test.

if (m_testingData)
{
   serviceResults = m_testingData;
}
else
{
   RequestorDataService ds = new RequestorDataService(m_url);
   ds.Message = CreateSOAPRequest();
   ds.Submit();
   serviceResults = ds.GetResults();
}

Does anyone see a problem with the above code fragment?  Some IoC love would go a long way here.

Testing | WTF
Saturday, March 10, 2007 8:55:23 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [2]  |  Related posts:
Fluent NUnit Assertions
The singleton that wasn’t
ReSharper 4.5 MsTest Plugin
MSTest ReSharper 4 Plugin
Mocks Should be Loose by Default
JsUnit Utilities Committed
Wednesday, March 14, 2007 1:39:38 AM (GMT Standard Time, UTC+00:00)
hey sneal

The line

RequestorDataService ds = new RequestorDataService(m_url);

is a prime candidate for IoC. You could eliminate the if-else by injecting (via constructor or property setter) a mock object to mock the DataService in an automated unit test.

public MyProdClass(RequestorDataService dataService)
{
this.ds = dataService;
}

public void DoStuff()
{
ds.Message = CreateSOAPRequest();
ds.Submit();
serviceResults = ds.GetResults();
}

That's my best shot at it...
vega
Wednesday, March 14, 2007 6:35:05 AM (GMT Standard Time, UTC+00:00)
That's what I was thinking too. I think that part of the problem is that the RequestorDataService is responsible for too much: creating the request message, sending the message, and getting the results.
Sneal
Comments are closed.