It is possible to write software that solves real business problems, cheaply and reliably. The recipe is well known, even though it's not easy to do.
I am a software developer. I'm happy to work as a programmer for ThoughtWorks, mostly in the Milano area. I used to teach at the Università dell'Insubria.
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.
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