Fog Creek Software
Discussion Board




Test First and HTML

I've done a couple of Extreme Programming projects with test-first coding, and testing HTML was always the vast exception to the rule.

We were coding in Java, so HttpUnit was available to test the webpages we were generating, but testing the content of HTML was a maintenance nightmare. HTML is presentation markup, not semantic, so you can't write the test before you've already decided on the presentation, if you change one piece of the presentation, your tests break.

So we abandoned test-first for webpages. XP purists will tell you it's possible to do test-first coding for webpages and GUIs, but I've never seen it done effectively or efficiently enough to justify it.

On the other hand, one thing test-first tends to enforce is good layering of the system, and good separation of logic from presentation. Because you want to test everything that's being displayed in the page, and because you can't test the page itself, the only possible way to do it is make sure that the logic is in separately testable objects.

A good compromise for Joel would be, whenever you separate some SQL statement out of a page, you get into the habit of writing a test for the thing you're extracting. A suite of unit tests is always good to have lying around, and while you're this close to all the code is probably the best time to add them - if you add them later you'll be a step or three back and you'll start forgetting things that were going through your head when you were in the midst of it all.

Charles Miller
Thursday, December 20, 2001

Excellent point!

I often found that if it is very hard to write a unit test this is a clear sign that we have design problems.

In the case of HTML it is a waste of time to test HTML, so we end up producing HTML through XML+XSL (Sorry, Joel - XML here is the best format).

It is easy to test XML output and it is always good for developer to think what data he want to return before he started coding.

Roman Eremin
Thursday, December 20, 2001

Our approach is to have library functions (which are UT'd) return complex data structures which are automagically turned into XML (which is not UT'd), which is then transformed using XSL stylesheets (which are not UT'd).

The idea is you have a clear separation of Libraries, Business Logic, and Presentation. We only UTLibraries because they're so easy to test. The presentation end of it we test with functional tests, but only very spottily and most definitely not with test-first programming.

Steve Willer
Friday, December 21, 2001

*  Recent Topics

*  Fog Creek Home