RE: [Jwebunit-development] Enhancement Suggestion.
Brought to you by:
henryju
Menu
▾
▴
RE: [Jwebunit-development] Enhancement Suggestion.
|
From: James E W. <JEW...@th...> - 2004-06-07 14:44:04
|
Nick, I think this is a good idea, and you can absolutely have a crack at it. As it happens, I'm aware of another group that has written a Mozilla driver which will be open sourced. The testing interface is XML scripts based on the jWebUnit API. Another possible browser-engine. One suggestion I'd make is to begin with the specifics of the Jacobi integration rather than the general interface - the purpose being to delay as long as possible modification of the existing jWebUnit classes (save merge headaches ;-)). HttpUnitDialog is the key class. It is the one driving httpunit and keeping state to make the assertions possible. Jim Jim Weaver Software Developer - ThoughtWorks Office : 615-850-4724 Cell : 312-286-7496 |---------+------------------------------------------------> | | Nick Neuberger | | | <Nic...@sn...> | | | Sent by: | | | jwe...@li...| | | ceforge.net | | | | | | | | | 06/04/2004 08:37 AM | | | | |---------+------------------------------------------------> >--------------------------------------------------------------------------------------------------------------| | | | To: jwe...@li... | | cc: | | Subject: RE: [Jwebunit-development] Enhancement Suggestion. | >--------------------------------------------------------------------------------------------------------------| Thanks for the reply.... My biggest justification are as follows: 1) There are two different types of testing tools. -browser-simulated test tools (http-unit, apache-http tests that cacoon tester uses). -ultimately only tests the server-side code. -true browser-integrated test tools. (basically none out there for java and free and open-source). -this is why I create an IE java-com wrapper api. My biggest problem with "browser-sims" is they will never be "true" browser tests. Because they aren't broswers that users use... Ie at my work....we use IE only. (right now atleast). 2) I tried staying with http-unit, but since its major lack of javascript support. The http-unit support....says its not really a problem with httpunit...its a problem with (I think) neko javascript api. It sucks... So, I tried to stay with httpunit. I started writing lots of TestCase classes, but everytime I had a problem with httpunit -> javascript. I would create a "diversion" routine in my code, just to traverse menus. our systems heavily rely on javascript to build fully dynamic menu systems. These "diversion" methods cames so problematic, that I gave up browser-sim api's such as httpunit. 3) Jim, I think the jwebunit api is awesome. It's generic. The codebase looks good, well designed. The main homepage says it all! A QA developer doesn't care about programming to an httpunit spec. They shouldn't be forced too. Much less even java developers. Ultimately, this is why I'm proposing these changes to jwebunit. The structure is all there to use muliple "testing" engines. I would very much like to be considered for these changes and if accepted by the community, I will do the refactoring effort. If accepted I'm willing to do the following: -Refactor the codebase to support an interface to the specfic running engine. -Get httpunit (plugin) working via the java interfaces. -Get my jacobie (plugin) project working via the java interface. Then down the road.........maybe other open-source developers will contribute.. -mozilla plugin -firefox... plugin. -netscape... -htmlunit... Ultimate, I need (for work) a "true" browser test to be called from: cruisecontrol (linux) -> ant -> junttasks -> jwebunit -> jacobie -> jacob (rmi-linux) -> (jacob-rmi) to windows server... -> invoking true web-based tests on windows. What do you think???? Comments???? See Ya, Nick Neuberger -----Original Message----- From: James E Weaver [mailto:JEW...@th...] Sent: Thursday, June 03, 2004 6:42 PM To: jwe...@li... Subject: Re: [Jwebunit-development] Enhancement Suggestion. Nick, We'll probably close off the forums and go with mailing lists. Javascript has always, always been a problem with jWebUnit, which is reliant on HttpUnit to act as its browser. The project jWebUnit was created from had almost no javascript (yay), hence the basic lack of concern for testing the results of javascript manipulations. Gradually, HttpUnit has improved javascript support, and the situation may be much better now. I'm really not sure - but will probably find out soon as I'll be attempting to use jWebUnit again on a small project that does have some basic javascript manipulation of form elements. I think that jWebUnit's strength is its API. It is simple and fits well with JUnit's API. The weakness is the reliance on HttpUnit as it's only engine. We discussed using HtmlUnit and tools that drive IE / Mozilla directly many times, but we never really had the driving reason to do it. I think supporting multiple engines would be a maintenance headache (figuring out if a reported bug is a jWebUnit problem or an HttpUnit problem is already a headache), but it is probably doable without a major refactoring. There is really only one class in jWebUnit that talks to HttpUnit - HttpUnitDialog. I think it is a request worth considering, but probably after the backlog of bugs and patch requests has been at least partially cleared out. Jim ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Jwebunit-development mailing list Jwe...@li... https://lists.sourceforge.net/lists/listinfo/jwebunit-development - - - - - - This e-mail message is intended only for the use of the individual or entity identified in the alias address of this message and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this e-mail message is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message from your system. Thank you. ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Jwebunit-development mailing list Jwe...@li... https://lists.sourceforge.net/lists/listinfo/jwebunit-development |
