NUnitAsp, my framework for test-driven development of ASP.NET, doesn't have much support for testing HTML tags. It has a lot of testers for ASP.NET server-side controls. This lack has been a source of confusion for people. In a recent email to the NUnitAsp mailing list, I shed some light on this situation:

The current version of NUnitAsp was designed for green-field TDD. It assumes that you're using ASP.NET to its fullest: using ASP.NET server controls rather than HTML whenever page behavior is involved; writing user controls rather than using includes; writing custom controls when you have client-side Javascript.

It bugs me that so many people use ASP.NET, a very cool framework for writing web applications, without using these features. Instead, they write regular HTML+Javascript and lose most of the architectural benefits of ASP.NET. (I have a terrible suspicion that this is because companies like to turn smart designers into dumb programmers.)

This irritation (hey, I'm an irritable guy) is why NUnitAsp doesn't have many HTML testers. I hoped people would just write proper ASP.NET code. But many don't, and I'm giving in:

The next version of NUnitAsp is going to enable testing of legacy code. Legacy code often uses client-side HTML tags rather than ASP.NET controls, and it frequently doesn't use IDs. There's a lot of other ugliness, such as putting Javascript directly in the page rather than writing custom controls. (Sadly, some people using ASP.NET to create a new application start out by creating "legacy code" because that's what they're familiar with.)

In order to enable NUnitAsp to test legacy code, I'm putting in a lot of new features. Multiple forms are now supported, as is the ability to emulate Javascript without writing a custom tester. Next on the list is testers for HTML controls and testing HTML tags that don't have an ID. XPath will probably be part of that, although I haven't decided for sure.

The current "no guarantees" release date for the next version is August or September.