Some help for Unit Testing, pre-part 33 and 1/3...

[eluser]t'mo[/eluser]
(Not part of my "official" Unit Testing series, but leading up to part III; see also parts one and two)

A.K.A., Why automated acceptance testing (sometimes) isn't enough, but it could also depend on your testing tool.

If you've followed along, you've seen the ways I've been thinking about how to do automated testing in a CI application. I've been trying to do as much as I could with minimal tools: PHP, CodeIgniter, a web browser, and a command line.

The other day, drizz815 asked a good question: how do you test your user interface? My answer was that I didn't at the time. That question, and my response to it, got me thinking. This got me thinking even more:

Code:

def test_sign_up
    visits "/"
    clicks_link "Sign up"
    fills_in "Email", :with => "[email protected]"
    select "Free account"
    clicks_button "Register"
    ...
  end

That wasn't the exact code I saw, but something similar. Seeing that example started the gears turning in my noggin; I had to try to do myself.

In part II, I stole the idea of invoking an arbitrary pathin into my application from the Cron example in the wiki. What do you (usually) get back when you type something at the command prompt? Text. And if I'm hitting some path into my app, the text I get back is (usually) HTML, which is parsable, and if it's parsable, it's also testable.

So, to finish out Part III of my series, I'd like to show how I've cobbled together a tool that does indeed parse the HTML, look for specific things, and run assertions on them. But I'm having a little trouble...because the "tool" I've cobbled together is actually written in Perl.

So, if I tell you what my "tool" does, can you point me in the right direction to find appropriate PHP-isms or libraries to fully convert this? Good; here's the list:

1. Must be able to parse HTML, at a minimum being able to find tags and attributes; even better, it will parse the HTML into some sort of DOM or other hierarchical structure

2. Must be able to...well, #1 is about it. Yes, it must be able to parse HTML. Into a DOM or other hierarichal structure. That's easy to work with. That's all.

Now, whether or not parsing HTML is a good idea for an automated tool is debatable. The one I'm currently using in Perl (HTML::TagParser, for the curious) is a little weak, in that it doesn't give a hierarcy of the HTML tags. Suppose I'm checking to see if a FORM has a certain INPUT - HTML::TagParser can find either of those, but it can't tell me that the INPUT is necessarily a child of the FORM - but what if I have two FORM's on the page?

-----

Now, about the automated acceptance testing not being enough? Will we ever get humans out of the mix? Maybe, but I'll have to improve my tools first. For example, I have a test on an app I'm currently working on that checks for a feedback form (TEXTAREA) and an optional name field (INPUT). My test said it passed...but my eyes said it failed. How about yours; does it fail? (See the attached file)
;-)