Test-Driven HTML: Why and How
daviddripps.com
daviddripps.com
For example, I use wget to spider a site then check both the Web server and wget logs for signs of trouble (404 or app server messages).
Watir is very handy for making sure things are OK on IE; I've hooked in calls to screenshots so I can crawl a site then look at a gallery of pictures for obvious rendering issues.
I'm not a Ruby guy so I've never used Watir. You pass the HTML string into Watir and it parses it in a headless web browser. Then you use Selenium WebDriver for generating screenshots to manually review? Makes sense.
My only concern is that it's not test-driven. My next post will be on browser testing as verification, but the reason I like TDD so much is because it forces me to think through the problem before writing code.
No, Watir scripts a running instance of IE. I have code in my Watir scripts that call out to a 3rd-party tool for taking screenshots. This is how I get a gallery of images showing all the pages in the app as actually seen in IE.
I also use Selenium to script a running browser instance; I do most of the heavy UI testing with that because I can run it on Ubuntu. It's with Selenium that I interact with forms, make sure ajax calls return correct values, pages have the right content, pages aren't giving me error messages, etc.
Some of this is also doable headless, and for many things headless (or just hitting the code via bacon or something) is of course faster, but using Selenium IDE I can record my interaction with a page then edit or expand the recorded script. So it's fairly trivial to create tests.
But I rarely do it test-driven. It's mainly to ensure that while I'm changing something in one place I don't inadvertently screw up a page someplace else that I may forget to check.
I think there was one app I tried to do the HTML TDD, but I soon found that it was much better for me to sketch out page design and flow and add tests as a I went.
"It's mainly to ensure that while I'm changing something in one place I don't inadvertently screw up a page someplace else that I may forget to check."
It all comes back to design by testing. Personally, my apps use a lot of layouts, views, and helpers so an automated way to check that a change in one place doesn't affect my UI somewhere else is paramount.
The key here is that it's automated. I use continuous integration, and introducing even one human element breaks the flow of quick pushes and updates.
As for sketching out page design, "form follows function." I'm not thinking about the look of the app at all. I'm not a designer, but once my HTML is written I can show a talented designer exactly what they have to work with to create the best UI/U possible. Basically, I'm not a fan of design-driven development.
I wish I could attach an image so you could see where I am with my current project. It's a logo at the top, followed by a list of links, a dropdown, another list of links, some content, etc. One on top of the other, no design at all. Black text, white screen. It is very clear though what the page is suposed to accomplish. Let the designer do their job, and I'll TDD my CSS when I turn their vision into code.