Re: [HtmlUnit] HttpUnit

[Rick B. <no...@ya...>]

Mike,

I've tracked HttpUnit for a while and just started
looking seriously at HtmlUnit.  The application I've
worked most with has a fair bit of JavaScript (most of
the buttons) so I couldn't use HttpUnit until that was
incorporated.  HtmlUnit wasn't on my radar screen
until recently so I hadn't even considered it.  A few
weeks ago I had the opportunity to revisit the test
automation topic and have been spending little bits of
time on it here and there (a dedicated block would be
nice but it just hasn't fit yet).

I've been building the same tests with both tools to
help decide if either has a real advantage or if there
is anything about my application that is beyond the
current level of support in either.  I started out
with an assumed "difference" between the two based on
the following text from the first paragraph of the
HtmlUnit home page on SourceForge (with which I
presume you are familiar).

"Which one is better for you depends on how you like
to write your tests. HttpUnit models the http protocol
so you deal with request and response objects.
HtmlUnit on the other hand, models the returned
document so that you deal with pages and form and
tables."

I'm not sure that the difference is quite as distinct
any more.  Their respective vocabularies are
definitely more HTML-centric and HTTP-centric, but in
either case I still find myself thinking about getting
the page, getting a form or table out of the page,
operating on what I've got, and submitting the result
(in the case of a form submit) or clicking on a button
or link.

Various people, at least in the HttpUnit community
where I've been on the mailing list longer, talk about
the fact that they end up refactoring common elements
out of their test code and into framework or helper
class code that simplifies the code flow in the test
itself.  I've been doing the same thing.

What I've found is that at the level I prefer to write
my test scripts, I've hidden the differences between
HtmlUnit and HttpUnit (except in cases where one only
supports "...ByID" and the other only supports
"...ByName").  My tests are built out of calls to
application-specific methods like login, logout, and
clickToNextWizardPage or more generic methods like
clickLinkWithName, selectFormByName, and setFormField.
 Implicit in my structure is a concept of "current"
for various things like page and form.

Much of my early test writing time has gone into the
discovery of these common features or the refining of
them.  When I had reached the point of being able to
navigate through one of the more complicated page
sequences in my application, I switched to the other
tool.  While I had to change class and method names, I
found that even the structure of my helper classes was
essentially the same.  I've also been able to evolve
them essentially in lock step so far.

There are certainly differences between the two at a
very nit-picky level.  Neither tool supports the
ability to operate uniformly by name, id, or label
text (i.e. not all variants of element reference are
supported in all cases where HTML defines them).  Both
are getting close but I suspect have been driven by
what has been requested (or via code submissions
adopted by their respective developers) in their
communities rather than specifically trying to be
uniform.  Since both are open source, I have no fear
that I would be unable add features I really need (and
submit them for incorporation if appropriate).

Right now, HtmlUnit has more built-in testing support
with methods like
HtmlPage.assertAllIdAttributesUnique.  HttpUnit seems
to have concentrated more on providing the engine that
gets the information back and forth and makes it
accessible to the test program than on capturing what
are likely to be common assertions about the content. 
My evaluation hasn't gotten to the point where these
differences have been drawn out enough to make a
critical difference.

As I get time to bring the evaluation to the point of
picking a tool I think I'll end up looking at somewhat
more subjective criteria like whether I think either
tool has greater momentum.  I'd have to give HttpUnit
the nod on greater visibility at this point (maybe I
stopped paying as much attention once I had found
HttpUnit but I suspect that HtmlUnit is still behind).
 I may have a look at whether either has a big
performance advantage over the other.  I guess I'd be
surprised to find such a difference but I may
ultimately be interested in using the same test
expression environment to write tests that stress the
application.

While this list is a good place to look for people
with cross-over experience, I suggest maybe you should
consider posting to the httpunit list as well.  You
might also try the JUnit YahooGroup.  There has been
at least a little bit of traffic on the matter of
examples for HttpUnit w/Javascript (and the most
recent JUnit post as of this writing was a plug for
HtmlUnit by J.B. Rainsberger).

Rick Berman
Ancilla SF LLC
ric...@ac...