Business Layer/Data Layer architecture,Test Driven Development and MVC May 18, 2009 at 7:54 pm
Using Test Driven Development (TDD) with ASP.NET can be a messy process if your not aware of some pitfalls. Say you wrote a button click event handler that does a couple of string conversions before calling the business layer:
protected void Button1_Click(object sender, EventArgs e)
{
string aString = //Do some string conversions
BusinessLayer bl = new BusinessLayer(aString);
string response = bl.GetSomeString();
Response.Write(response);
}
You also have a unit test for the Business Layer’s GetSomeString method:
{
EnsureReturnIsNotEmpty()
{
BusinessLayer bl = new BusinessLayer();
string response = bl.GetSomeString();
Debugger.Assert(response == “”);
}
}
In this scenario, it is possible that your unit test will pass even when the user interface fails. If a string conversion in the ASP.NET page breaks (See the button_click event handler) this will not be tested by the unit test.
To fix this issue you can move the code (//Do some string conversions) to the business layer. You are still left w/ code in the Button Click Method (E.G. Response.Write()). This does not provide the clean seperation of layers that is offered by the MVC design pattern, therefore TDD cannot be fully entrusted to ensure your code will run. Though, if you keep the code in the ASP.NET code behind pages to a minimum. Your problems beyond the help of TDD should remain at a minimum as well. Perhaps Microsoft’s new ASP.NET MVC will solve this issue: http://www.asp.net/mvc/whatisaspmvc/