Re: [Jwebunit-development] Enhancement Suggestion.

[Martijn D. <ma...@da...>]

Nick Neuberger wrote:

 > FYI - I just posted this to the Forum....  Forum....Mailing
 > Lists,,,,etc. All these different support mechanisms....  The
 > forums should be removed and only use the mailing list.  :-}

I'll take it up with Jim. :-). I'm subscribed to both, so I'll still
receive all messages, but answering through the forum is a pain. +1
from my account.

 > My 2cents. I'm very glad to see people ambitous about keeping the
 > "main" jwebunit" and NOT forking... Users need to understand thats
 > the way open-source is. Most contributors don't get paid a dime...
 > They write the open-source code for a specific (contracting-type)
 > project, then go on to another project. Anyway...off my soap-box...
 > (I mean no harm when I say that......looks like the projects is
 > being revived.).

It's true, must projects (even closed source ones) are built for an
itch, be it a business itch, or personal. Most projects rarely get
supported after the itch has gone. If it works, don't break it.
However, I'm honoured to be admitted to the development team of
jWebUnit, and I hope I can keep scratching my itch for a long time.

 > I tried using jWebUnit a while back and had too much trouble. Not
 > really from webunit, but from HttpUnit and its lack of javascript
 > support...It's horrible....

Did you upgrade httpunit? I've never *really* tested javascript with
jwebunit, mainly because our projects try to keep javascript usage to
a bare minimum, so perhaps I'm talking out of my neck.

 > I would like to make a suggestion, and I can start creating the
 > ground-work.... Keeping the same jwebunit / layer, but creating
 > some java interfaces to implement different kinds of
 > webtesting....ie...."httpunit", "ie-jacobie", "etc".

This sounds interesting, but I don't know what, javascript support of
httunit aside, you might accomplish by using another webclient. The
target of the jWebUnit tests, is in my opinion, the content generation
of the webpages. Thereby performing an integration/functional test of
the webapplication. If one wishes to test different renderings for the
webpages based on the client (internet explorer, mozilla, etc), then
perhaps HTTPUnit needs support to let it identify itself as such browser.

 > I would like to run the exact same webunit tests using the same
 > code, just switching to a different "WebTester".
 >
 > //psuedo scratch. JWebUnit.installTester(JWebUnit.HTTPUNIT); or
 > JWebUnit.installTester(JWebUnit.JACOBIE);
 >
 > //same tests as usuall, just all interaction with a specific
 > "tester" will be delegated via the "interface" classes.

Technological it is conceivable to make jWebUnit 'httpclient'
agnostic, the HTTPUnitDialog is just one strategy. Shouldn't be too
hard in my opinion, provided the targetbrowser can easily be
manipulated via Java.

 > 2) I'm very willing to produce the code to do it, at least on the
 > jWebUnit side.
 >
 > 3) My main goal, is that I don't want to reinvent "jwebunit" to be
 > "browser" ized...

Reinventing is not always a good thing. However, my main question is,
what do you gain by 'browserizing' jwebunit? I'm not opposed to
extending jWebUnit, but I need/want to know what the problem is, and
why browserizing is the solution.

Martijn Dashorst