I know that the reason that Microsoft came out with ASP.NET MVC was to make it simpler to do Test Driven Design (TDD) for ASP.NET. However, I have a rather large brown field (existing) application in ASP.NET WebForms that I would love to implement some TDD type functionality in. I'm assuming that there IS a way to do this, but what are some viable options?
You can run HTTP-based tests to test the high level functionality. The best thing would be to encapsulate code-behind code into your business layer and run unit tests on it.
Microsoft introduced ASP.NET MVC because they thought they could make money from an untapped market - those who feel that Web Forms are too "heavyweight", and who are programming using a lighter-weight framework. This includes those who are accustomed to the MVC paradigm.
It also includes those who couldn't figure out how to do unit tests in web forms, and who want to use unit tests and TDD.
The way to do it with web forms, as with anything else, is to separate everything but the UI code into separate classes in a class library. Use TDD to develop those classes.
The next layer of controversy is whether it's necessary to use TDD to develop the remainder of the code: the markup, client-side code, user interactions, etc. My answer is that if you've got the rest isolated and tested, that it's not worth the trouble to use TDD for this.
Consider: your pages need to have a particular appearance. Are you going to write a failing unit test to prove that you are using CSS correctly? To prove that you're using the correct CSS styles? I don't think so.
To clarify: In TDD, we start with a failing unit test. We then make the simplest possible changes that will make the test succeed.
Imagine using TDD for a web page. What failing tests will you produce?
- Test that page is well-formed HTML
- Test that page includes the correct title
- Test that page includes
- "Enter ID" label
- An id textbox
- A data grid
- A "Go" button
- Test that data grid is empty after a GET
- Test that grid loads with data from customer 1 when "1" is entered into the text box and "Go" is clicked.
And none of the above tests for the appearance of the page. None of it tests the client-side behavior of any JavaScript on the page.
I think that's silly. Instead, test your DAL method that retrieves data based on the ID. Make sure it returns the correct ID for id 1. Then, how long will it take to manually test the page to make sure it looks correct, you can enter the "1" and clock "Go", and that the data that appears in the grid is the correct data for customer 1?
Test-Driven Development and automated unit tests are meant to test behavior. The UI of a web form is mostly declarative. There's a large "impedance mismatch" here.
You can use the official Unittest Framework: http://msdn.microsoft.com/en-us/library/ms182526(VS.80).aspx
First of all, its really hard to test WebForms. But if you break out logic to Controllers/Presenters like the MVC/MVP pattern you can at least test the presenters.
Pseudo-code
Default.aspx
public void Page_Init(object sender, EventArgs e) {
_presenter = new DefaultPresenter(IDependencyOne, IDependencyTwo etc) //Init new presenter, either from IoC container of choose or "new-it-up"
}
public void Save() {
_presenter.Save(txtValue.Text)
}
Than you can easily test the presenter in isolation at least =)