jwebunit-development Mailing List for JWebUnit (Page 86)
Brought to you by:
henryju
Menu
▾
▴
jwebunit-development — Concerns current development ongoing in JWebUnit.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(98) |
Jul
(45) |
Aug
(49) |
Sep
(90) |
Oct
(28) |
Nov
(18) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(14) |
Feb
(21) |
Mar
(52) |
Apr
(39) |
May
(61) |
Jun
(35) |
Jul
(42) |
Aug
(31) |
Sep
(34) |
Oct
(16) |
Nov
(14) |
Dec
(61) |
| 2006 |
Jan
(39) |
Feb
(11) |
Mar
(29) |
Apr
(29) |
May
(30) |
Jun
(145) |
Jul
(61) |
Aug
(40) |
Sep
(36) |
Oct
(66) |
Nov
(50) |
Dec
(11) |
| 2007 |
Jan
(30) |
Feb
(1) |
Mar
(47) |
Apr
(9) |
May
(36) |
Jun
(13) |
Jul
(7) |
Aug
(5) |
Sep
(6) |
Oct
(3) |
Nov
(11) |
Dec
(36) |
| 2008 |
Jan
(12) |
Feb
|
Mar
(4) |
Apr
(29) |
May
(1) |
Jun
(8) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
(77) |
Nov
(107) |
Dec
(46) |
| 2009 |
Jan
(17) |
Feb
(13) |
Mar
(27) |
Apr
(5) |
May
(8) |
Jun
(17) |
Jul
(10) |
Aug
(25) |
Sep
(15) |
Oct
(4) |
Nov
(4) |
Dec
(10) |
| 2010 |
Jan
|
Feb
(6) |
Mar
(12) |
Apr
(15) |
May
(4) |
Jun
(5) |
Jul
(9) |
Aug
(5) |
Sep
(5) |
Oct
(63) |
Nov
(9) |
Dec
(1) |
| 2011 |
Jan
(9) |
Feb
(3) |
Mar
(15) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(14) |
Sep
(15) |
Oct
(11) |
Nov
(1) |
Dec
(2) |
| 2012 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
(17) |
Sep
(8) |
Oct
(1) |
Nov
(17) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(13) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(13) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: Vivek V. <vi...@ya...> - 2004-06-10 01:51:26
|
All Time and again I am hearing comments on the quality of test coverage for jWebUnit. So I spent this weekend trying to integrate with a code coverage tool called GroboUtils. The good news is that our coverage is reasonable (80%). But there are a couple of important things to do
Improve coverage by writing more test cases (We need to get to the 90%+ range)
Make Grobo toolkit an integral part of the build
I think I can do item #2 easily. (I have already done it!) would it make sense for me to commit these changes? Please let me know.RgdsVivek
Summary Coverage Report of jWebUnitReport generated on:Jun 6, 2004 12:23:58 PM Overview Package Class FRAMES NO FRAMES All Classes'); } //-->All Classes
---------------------------------
FunctionLineCountTOTALfunctions CoveredTotal functions% Coveredlines CoveredTotal lines% CoveredUnits CoveredTotal Units% CoveredAll Packages28234980.8063879180.669201,14080.70PackageFunctionLineCountTOTALfunctions CoveredTotal functions% Coveredlines CoveredTotal lines% CoveredUnits CoveredTotal Units% Coverednet.sourceforge.jwebunit.util1128.3332711.1143910.26net.sourceforge.jwebunit27533183.0859672182.668711,05282.79net.sourceforge.jwebunit.util.reflect66100.00394390.70454991.84Generated with GroboUtils Code CoverageJun 6, 2004 12:23:58 PM
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger |
|
From: Vivek V. <vi...@ya...> - 2004-06-10 01:45:13
|
Finally, I was able to get on the mailing list. The list would never accept my usual email address and I am using this yahoo account to send mails. I would ideally like to get on the list with my other email address. Can the list administrator help? my email address of choice is vivek at magic hyper cauldron dot com. Thanks Vivek __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ |
|
From: Martijn D. <ma...@da...> - 2004-06-07 23:36:46
|
Status report on the release 1.2 - the list of developers is cleaned up, new active developers are enlisted Finished: * Vivek Venugopalan * Nick Neuberger * Martijn Dashorst are added as developers and Martijn Dashorst is added as admin. Old, inactive members have been removed. - we upgrade the dependend libraries to their latest released versions Finished. Is integrated into CVS - HEAD. Build using maven *and* ant both work with the new dependencies. - we make all tests pass, need to check the current tests, whether there are no false positives How far are we here? I got confirmation from Vivek that the cookie support *does* work, but that the PseudoServer doesn't support cookies. What should we do with the test? - we close all patches which already have been committed to CVS Jim is busy going through all past changes. How long do you need? - we tag the repository with R1_2, perhaps even create a release branch (as is prescribed in 'Pragmatic version control')? Not done yet. - we build a new release 1.2 Not done yet. - we release 1.2, and distribute it also to the maven repository (http://www.ibiblio.org/maven/jwebunit/jars) (need to figure out how to do that) Not done yet. - we make a release plan for version 1.3 Not done yet The timeschedule (my interpretation): Status Date Description V - june 1 - administration of the developer list finished V - june 2 - upgrades of the libraries commited in CVS, all tests pass X - june 6 - tests are checked, all tests pass (no dummy tests) X - june 7 - release preparation - - june 10 - release of version 1.2 - - june 11 - attempt to upload jwebunit-1.2.jar to ibiblio - - june 14 - battleplan for release 1.3 ready (which features go in, etc.) Time is running out for this schedule. I'll look into the tests tomorrow evening (girlfriend permitting). The release of june 10 is still possible. Martijn Dashorst |
|
From: Nick N. <Nic...@sn...> - 2004-06-07 21:47:08
|
> OK, we'll create a branch for you (and others) to work on for this > feature. The only thing we wish to do is to wait for the > release of 1.2 > so we all have a defined starting point. This release should be on > friday, we hope you can wait that long. No problem... Send an e-mail to the list after 1.2 is good and also the branch is created.. I can then begin the integration effort with the jacobie api for internet explorer. See Ya, Nick - - - - - - 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. |
|
From: Martijn D. <ma...@da...> - 2004-06-07 21:12:39
|
Nick Neuberger wrote: >>Shall we create a branch for this functionality? Then we >>(Jim, Vivek and >>I) can work on the main branch for the release, >>and later, when you have finished the new functionality, >>merge it with >>the main branch. >> >> >Yes.... A branch should be created. It seems the most logical. Then I can >commit when I have a good subset working. > >This would ensure the main head stream will not be broken from my changes. >Later when proven successful, then a final merge back into the head stream >will give light to the new changes. > > OK, we'll create a branch for you (and others) to work on for this feature. The only thing we wish to do is to wait for the release of 1.2 so we all have a defined starting point. This release should be on friday, we hope you can wait that long. >If this sounds like a plan, please include me as a project member so I (or >someone else) can create the branch. It would be ALOT easier creating >another branch. As I could commit / synch my changes on a regular basis. >Any thoughts.. > > Consider yourself added. Martijn |
|
From: Martijn D. <ma...@da...> - 2004-06-07 21:08:22
|
Here's a short manual for using maven to build jwebunit, or to generate
the infamous website. I also created the doc in the xdocs, so if you
generate the website (see below) then you'll also have this manual.
Installing and configuring maven
First you need to download the latest maven, which currently is
maven-1.0-rc3 (release candidate 3), make sure you download the archive,
not the exe installer.
Installing maven should be easy: unzip the file to any directory you
like, let's say: c:\maven-1.0-rc3
Next you need to do 3 things:
* add an environment variable MAVEN_HOME which points to the install
directory of maven, i.e. c:\maven-1.0-rc3
* add MAVEN_HOME\bin to your path (use the variable, this way, you can
switch more easily when a new version arrives)
* add to your home directory (under windows 2000 and XP: C:\Documents
and Settings\<username>) a file called build.properties, and put the
following entries in it:
maven.home.local=${maven.home}/cache
maven.repo.local=c:/maven-repository
maven.repo.remote=http://www.ibiblio.org/maven
You can replace the maven.repo.local entry with a directory of your
liking. I advise you to make the directory seperate from the maven home
directory. Maven downloads all dependencies into this directory. This
repository can be shared among maven versions, and even developers on
the same machine. The cache directory (the first entry) can't be shared
between maven versions, so this should stay within the maven home directory.
Using maven
Usage of maven is very simple: just run in the jwebunit directory, where
the project.xml file resides, the command:
maven
You will see maven downloading all kinds of stuff, and compiling,
testing and building a jar file:
<!-- start log -->
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-rc3
Plugin cache will be regenerated
Directory c:\maven-repository bestaat niet. Probeer hem aan te maken.
Probeer junit-3.8.1.jar te downloaden.
........
.
Probeer nekohtml-0.8.1.jar te downloaden.
....
.
Probeer js-1.5R4.1.jar te downloaden.
.......................
.
Probeer xml-apis-1.0.b2.jar te downloaden.
.....
.
Probeer xercesImpl-2.6.2.jar te downloaden.
....................................
.
Probeer servletapi-2.3.jar te downloaden.
...
.
Probeer httpunit-1.5.4.jar te downloaden.
...............
.
Probeer dom4j-1.4-dev-8.jar te downloaden.
.....................
.
Probeer commons-jelly-20030902.160215.jar te downloaden.
......
.
Probeer commons-jelly-tags-jsl-20030211.143151.jar te downloaden.
..
.
Probeer commons-jelly-tags-log-20030211.142821.jar te downloaden.
..
.
Probeer commons-jelly-tags-velocity-20030303.205659.jar te downloaden.
..
.
Probeer commons-jelly-tags-xml-20030211.142705.jar te downloaden.
..
.
Probeer commons-logging-1.0.3.jar te downloaden.
..
.
Probeer maven-1.0-rc2.jar te downloaden.
........
.
Probeer velocity-1.4-dev.jar te downloaden.
..............
.
Probeer velocity-dvsl-0.45.jar te downloaden.
..
.
Probeer maven.jar te downloaden.
.....
.
Probeer isorelax-20030108.jar te downloaden.
........
.
Probeer jing-20030619.jar te downloaden.
....................
.
Probeer xerces-2.4.0.jar te downloaden.
..............................
.
Probeer commons-io-20030203.000550.jar te downloaden.
...
.
Probeer commons-net-1.0.0.jar te downloaden.
.....
.
Probeer commons-httpclient-2.0-beta1.jar te downloaden.
........
.
Probeer commons-lang-1.0.1.jar te downloaden.
....
.
Probeer jsch-0.1.5.jar te downloaden.
...
.
Probeer commons-jelly-tags-antlr-20030211.143720.jar te downloaden.
..
.
Probeer antlr-2.7.2.jar te downloaden.
..............
.
build:start:
java:prepare-filesystem:
java:compile:
[echo] Compiling to C:\workspace\jWebUnit/target/classes
java:jar-resources:
test:prepare-filesystem:
test:test-resources:
test:compile:
test:test:
[junit] Running net.sourceforge.jwebunit.ExpectedTableAssertionsTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0,594 sec
[junit] Running net.sourceforge.jwebunit.ExpectedTableTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,343 sec
[junit] Running net.sourceforge.jwebunit.FormAssertionsTest
[junit] Tests run: 23, Failures: 0, Errors: 0, Time elapsed: 2,469 sec
[junit] Running net.sourceforge.jwebunit.FormSubmissionTest
[junit] Tests run: 18, Failures: 0, Errors: 0, Time elapsed: 2,969 sec
[junit] Running net.sourceforge.jwebunit.FramesAndWindowsTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 1,328 sec
[junit] Running net.sourceforge.jwebunit.JavaScriptEventsTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0,907 sec
[junit] Running net.sourceforge.jwebunit.NavigationTest
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 2,282 sec
[junit] Running net.sourceforge.jwebunit.ServletUnitTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0,687 sec
[junit] Running net.sourceforge.jwebunit.TableAssertionsTest
[junit] Tests run: 13, Failures: 0, Errors: 0, Time elapsed: 1,531 sec
[junit] Running net.sourceforge.jwebunit.TestContextTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0,36 sec
[junit] Running net.sourceforge.jwebunit.TextAndElementWalkerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,328 sec
[junit] Running net.sourceforge.jwebunit.util.reflect.MethodInvokerTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0,328 sec
[junit] Running net.sourceforge.jwebunit.WebAssertionsTest
[junit] Tests run: 15, Failures: 0, Errors: 0, Time elapsed: 1,828 sec
[junit] Running net.sourceforge.jwebunit.WebCookieTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,422 sec
jar:jar:
[echo] Warning: shortDescription is greater than 49 characters -
trimming for specification title.
[jar] Building jar: C:\workspace\jWebUnit\target\jwebunit-1.2.jar
BUILD SUCCESSFUL
Total time: 1 minutes 53 seconds
Finished at: Mon Jun 07 23:06:15 CEST 2004
<!-- end log -->
You have succesfully built the jwebunit jar file.
Generating the website using maven
This one is also quite simple:
maven site
After downloading lots and lots of jar files, maven will build the
website which contains junit results, checkstyle results, and the like.
You can find the website in the target/docs directory: just open the
index.html in your browser.
Doing a release build with maven
TODO
|
|
From: Nick N. <Nic...@sn...> - 2004-06-07 17:59:43
|
> Shall we create a branch for this functionality? Then we > (Jim, Vivek and > I) can work on the main branch for the release, > and later, when you have finished the new functionality, > merge it with > the main branch. Yes.... A branch should be created. It seems the most logical. Then I can commit when I have a good subset working. This would ensure the main head stream will not be broken from my changes. Later when proven successful, then a final merge back into the head stream will give light to the new changes. If this sounds like a plan, please include me as a project member so I (or someone else) can create the branch. It would be ALOT easier creating another branch. As I could commit / synch my changes on a regular basis. Any thoughts.. Thanks, Nick Neuberger - - - - - - 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. |
|
From: Martijn D. <ma...@da...> - 2004-06-07 17:26:05
|
Nick Neuberger wrote: >I'm hoping you guys use eclipse as your dev editor. This is what I'm using. >I will try and pull down the jwebunit via eclipse and sf.net cvs repo... >and get working in the next couple of days....weeks. > >I'll take your suggestion.... Merge can be very difficult but eclipse does >make it ALOT easier... I'll keep my workspace updated to try and prevent >merge conflicts..... > > Shall we create a branch for this functionality? Then we (Jim, Vivek and I) can work on the main branch for the release, and later, when you have finished the new functionality, merge it with the main branch. Martijn |
|
From: Nick N. <Nic...@sn...> - 2004-06-07 15:43:34
|
I'm hoping you guys use eclipse as your dev editor. This is what I'm using. I will try and pull down the jwebunit via eclipse and sf.net cvs repo... and get working in the next couple of days....weeks. I'll take your suggestion.... Merge can be very difficult but eclipse does make it ALOT easier... I'll keep my workspace updated to try and prevent merge conflicts..... See Ya, Nick Neuberger -----Original Message----- From: James E Weaver [mailto:JEW...@th...] Sent: Monday, June 07, 2004 9:44 AM To: jwe...@li... Subject: RE: [Jwebunit-development] Enhancement Suggestion. 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 ------------------------------------------------------- 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. |
|
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 |
|
From: Nick N. <Nic...@sn...> - 2004-06-04 13:39:32
|
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. |
|
From: James E W. <JEW...@th...> - 2004-06-03 23:42:38
|
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 |
|
From: Martijn D. <ma...@da...> - 2004-06-03 22:05:49
|
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 |
|
From: Nick N. <Nic...@sn...> - 2004-06-03 21:40:38
|
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. :-} 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.). 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.... I'm currently working on an API that works directly with true web-browsers such as Internet Explorer via (Jacob or Java-Com-Bridge). Here is the project I have created. <http://sourceforge.net/projects/jacobie/> 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". 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. 1) Jim... If you are the main guy. Are you interested in a possible major "refactoring" effort for jWebUnit. 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... jWebUnit has a very good foundation to build on.... Thoughts!!! Nick Neuberger - - - - - - 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. |
|
From: Martijn D. <ma...@da...> - 2004-06-01 22:48:25
|
These are the dependencies: httpunit-1.5.4.jar js-1.5R4.1.jar junit-3.8.1.jar nekohtml-0.8.1.jar servletapi-2.3.jar xercesImpl-2.6.2.jar xml-apis-1.0.b2.jar Martijn Dashorst |
|
From: Martijn D. <ma...@da...> - 2004-06-01 21:11:13
|
Contrary to popular believe, jWebUnit shows some signs of being alive. Here's the plan as I see it: - the list of developers is cleaned up, new active developers are enlisted - we upgrade the dependend libraries to their latest released versions - we make all tests pass, need to check the current tests, whether there are no false positives - we close all patches which already have been committed to CVS - we tag the repository with R1_2, perhaps even create a release branch (as is prescribed in 'Pragmatic version control')? - we build a new release 1.2 - we release 1.2, and distribute it also to the maven repository (http://www.ibiblio.org/maven/jwebunit/jars) (need to figure out how to do that) - we make a release plan for version 1.3 The timeschedule (my interpretation): june 1 - administration of the developer list finished june 2 - upgrades of the libraries commited in CVS, all tests pass june 6 - tests are checked, all tests pass (no dummy tests) june 7-10 - release preparation june 10 - release of version 1.2 june 11 - attempt to upload jwebunit-1.2.jar to ibiblio june 14 - battleplan for release 1.3 ready (which features go in, etc.) Please feel free to comment on this plan. With regards, Martijn Dashorst |
133 messages has been excluded from this view by a project administrator.
