That's naive but potentially valid. A better approach might be to use a framework that understands how to parse xml so that silly things like white space or character entities don't break the test. Better than that would be to use something that understands how to parse HTML in a manner similar to what the browser does.

However, all of those solutions couple you to an intermediate form that isn't really that interesting. A better approach would be to validate the actual browser components that the user interacts with. The place to do that in is in the browser.

Now, some would suggest that the way to test in the browser is to use a tool like e.g. Selenium against a running server, but then that couples your front end tests to your back end, which is a whole new kind of pain. I used to do it that way and I can tell you that it is less than a fun time.

What I would do is decouple the front end HTML code from the back end server code. The way to do that is to use static HTML and have the dynamic, server parts handled by javascript. You can test the way the javascript interacts with the static HTML bits in the browser without the need for a running server. You can test the way javascript interacts with the server by writing interaction tests using test doubles in javascript. Then you can write HTTP tests that interact with the server side functionality (Without running any javascript.)

This approach works very well provided that this sort of architecture works for your problem space. If you need to generate HTML dynamically on the server side then your back to needing to write integration tests that include the browser and the server (i.e. you have tight coupling across a system boundary.) Another approach would be to use a rich client side technology with better testing support like Flash/Flex.

Adam Sroka on the TDD mailing list