views:

707

answers:

4

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?

A: 

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.

Sergey
+9  A: 

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?

  1. Test that page is well-formed HTML
  2. Test that page includes the correct title
  3. Test that page includes
    1. "Enter ID" label
    2. An id textbox
    3. A data grid
    4. A "Go" button
  4. Test that data grid is empty after a GET
  5. 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.

John Saunders
So, just to clarify: Separate my UI layer out from my business logic. I'm guessing I'll have to change my gridview databinds out for something else. Do all of my controls need to be generated in the code behind? Would that make the separation easier?
Jeremy Sullivan
Your answer has been very enlightening. Thank you, John.
Jeremy Sullivan
I hope it helps. Please feel free to comment here or ask another question if I missed the base somewhere. I can imagine some sorts of complex UI interactions where TDD might be helpful, but those would be rare. If you hit one, let us know.
John Saunders
@Downvoter: words speak louder than -2. Please say what your problem is.
John Saunders
+1: Nice answer, John.
Jim G.
@John Saunders: *Microsoft introduced ASP.NET MVC because they thought they could make money from an untapped market* - Does this mean that you're bearish on ASP.NET MVC? Or are you making a non-opinionated assertion?
Jim G.
Hi, @Jim: I think I was just stating a fact.
John Saunders
A: 

You can use the official Unittest Framework: http://msdn.microsoft.com/en-us/library/ms182526(VS.80).aspx

ChaosSpeeder
That may be official, but it's crap. It assumes you're using a Web Site "project" to begin with, then proceeds to totally fail in a TDD environment (which is what this question is about).
John Saunders
+2  A: 

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 =)

Kenny Eliasson
Can you give me specifics on what stuff would be on each side of the separation?
Jeremy Sullivan
I usually only let the page take care of UI-rendering and transforming values from QueryString/Form/Viewstate and then calling the presenter that talks with other services and/or repositories.
Kenny Eliasson
These patterns are a formalizaton of what I was suggesting. I think they can be nice as a development paradigm, but I think they overshoot the mark a bit in terms of TDD. To my mind, the purpose of tests in TDD is to create code that is missing a set of bugs by creating tests that prove the bugs are absent. I think once you get to UI, you weren't going to have a lot of those bugs in any case. The bugs you would have had would be better found by using manual testing, perhaps augmented by an automation framework, but not TDD and not even purely unit tests.
John Saunders