[Webtest] HttpUnit's not unit testing
Thu, 28 Mar 2002 13:49:32 +0100
Nice thread. I just cannot resist to comment... :-)
> [mailto:email@example.com]On Behalf Of Ben Cox
> Sent: Samstag, 23. Marz 2002 10:22
> Subject: [Webtest] HttpUnit's not unit testing! (was Re: Dynamic Field
> While I definitely agree with the concept of the unit tests being in
> the language of the API they are testing, I do not think that HttpUnit
> meets that criteria at all! The interface that HttpUnit tests is an
> HTML interace over http, not a Java API interface, and the
> request/response pattern of a web-app is not even object-oriented!
> HttpUnit is really for functional testing, in my humble opinion,
> while ServletUnit is for unit testing the elements of the web
> application that can't be delegated from a servlet, and JUnit itself
> will suffice for testing the bulk of your logic (if you use a Controller
I fully agree.
> [..] My unit tests, on the other hand, tend to focus on
> the model rather than the view, and don't really need to involve the web
> server much.
Our Unit Tests are for every bit of _our_ _logic_. While most of the
logic is in the model, we do Unit Testing for the view, if it contains
logic (e.g. paging of tables). None of the Unit Tests need a server
> So, I see no reason to insist on writing Java code to describe
> customer-defined tests of the HTML interface!
With reasonable Unit Tests at hand, I don't see it either.
This is one reason for not augmenting WebTest with the full set of
programming language control structures (if, else, for, etc.).
However, the world is not perfekt. Some projects call for more advanced
features of WebTest to enable testing with more "logic" involved.
These Projects are typically the ones that did not make their
homework in Unit Testing. For those projects, using HttpUnit directly
may a viable solution.
> [..] In fact, since XML is closer to HTML than
> Java, it probably makes the intention a little more clear to do it
> WebTest-style, which is why I am so excited about WebTest!
Cool. I've never seen it like that before. I think this point should go
to the website. Do you mind being cited there?
> had quite a few
> NullPointerExceptions just trying to ensure form fields were empty, for
Don't hesitate to post any errors to the mailinglist.
> I'm afraid it's not quite evolved enough for it to meet our
> needs right now. We'd like to work toward an interface to make the
> specification of functional tests for web sites easy on our customers,
> but it simply requires they be able to do more.
What would be more "evolved", what would be "more"?
> I'm certainly willing to work on expanding webtest, and intend to do
> so over the next little while in order to finish my deliverables for a
> client, but my current suspicion is that the exposure of what will truly
> be enough of HttpUnit's functionality may just require substantial
> change to and expansion of WebTest's XML schema.
Changing the schema is no issue, as long as we can keep it "compatible".
> I think it's just a
> little too flat (very few nested tags) to add that much functionality to
> without confusion.
Make a suggestion.
> I don't want to start down that road just yet, and I certainly don't
> want to do it without discussion and possibly collaboration with those
> of you who form this WebTest community, but in the next couple of weeks
> I'm pretty likely to need that functionality one way or the other! Is
> anyone else interested in going in that direction? Perhaps a WebTest
> Mark 2 (aka HttpAntUnit) whose XML schema is based more directly on
> HttpUnit's API?
This list is the right place for this kind of discussion.
Maybe some points on how we work.
- Start with the real problem of a real project. No speculation.
- Think, whether this is really a problem the user is concerned with.
- Assess, whether a Unit Test would be easier.
- Write the WebTest. Do it like a user would do it. Add it to the selftest
- Run the test. It fails. Look at how it fails and how failure gets
- While implementing, try to do it in a pair. Do it (unit-) test first. Add
it to the
- Use the build.xml for local builds and tests.
- Add some more tests (e.g. in <NOT> elements to test how it fails)