Hi Julien, Thanks for your response.
I have raised the issue at https://sourceforge.net/tracker/?func=detail&aid=3395872&group_id=61302&atid=497982 I hope to be able to produce a test case for the frames issue if I get time. yours Tim On 21 August 2011 17:52, Julien HENRY <henr...@yahoo.fr> wrote: > Hi Tim, > > See my comments inline. Anyway thanks for sharing. > >>________________________________ >>De : Tim Pizey <t...@paneris.org> >>À : jwebunit-users@lists.sourceforge.net >>Envoyé le : Samedi 20 Août 2011 1h00 >>Objet : [JWebUnit-users] Issues upgrading from version 2.2 to version 3 >> >>Hi, >> >>Thanks to all the JWebUnit team, and especially to Julien for his >>attention to every message. >> >>This is to record the issues I have encountered in upgrading to >>version 3.0 from version 2.2. >> >>I have downloaded the source and built locally, but had to setup a >>toolchain.xml in my .m2 directory and disable >>header checking before mvn install would work. >>I would prefer not to rely upon toolchain.xml as I would wish to build >>this under Jenkins and do not wish to set a universal toolchain. >>Can this not be moved into the pom.xml file? >> > > This is not really a "usability" problem as it is only required if you plan > to build JWebUnit by yourself. It is well documented [1]. > Usually I am running Maven with JDK 1.6 when JWebUnit should be compatible > with JDK 1.5. In the past when I was building with JDK 1.5 and JWebUnit was > supposed to be JDK 1.4 compliant, usage of String.startsWith was unnoticed, > even if compiler has -target 1.4 flag. That's why I introduced toolchains > that is the standard Maven way to compile with a given JDK even when Maven is > started with another. > But I agree this is really annoying to setup, make the build not portable, > ... I am aware of 2 other options: > - use a property to specify JDK path to the compiler plugin. Same issue > than toolchains you would have to set this property in your settings.xml > - compile with the same JDK than Maven is run with, but use animal-sniffer > to detect bad API usage. This is my preferred solution but I had no time to > set it up. No very high priority for me. > > >>======== >> >>The class WebTestCase has been deprecated with the message 'use JUnit >>4' : I have no intention of using JUnit4, >>I do not think it is an improvement on JUnit3, there are many who >>share my view. >>The JUnit3 project is alive and well and is not going away anytime soon. > > > Could you please point me to the project page were it is alive? Just curious. > > >>Please remove deprecation. > > > I do not plan to remove JUnit 3 support in JWebUnit (in fact this is > automatically generated so it doesn't require any effort) but on the other > hand I will no more validate that it works. So this is like "use it at your > own risk". > I would like to hear other voices here: keep or remove deprecated flag on > JUnit 3 stuff? > > >>========= >> >>HtmlUnitTestingEngineImpl.gotoPage no longer returns the failing status >> >> public void gotoPage(URL initialURL) throws >>TestingEngineResponseException { >> try { >> wc.getPage(initialURL); >> win = wc.getCurrentWindow(); >> form = null; >> } catch (FailingHttpStatusCodeException ex) { >> // only throw exception if necessary >> if (!ignoreFailingStatusCodes) { >> throw new TestingEngineResponseException( >> "unexpected status code ["+ex.getStatusCode()+"] >>at URL: ["+initialURL+"]", ex); >> } >> } catch (IOException ex) { >> throw new RuntimeException(ex); >> } >> } >> >>should be >> >> public void gotoPage(URL initialURL) throws >>TestingEngineResponseException { >> try { >> wc.getPage(initialURL); >> win = wc.getCurrentWindow(); >> form = null; >> } catch (FailingHttpStatusCodeException ex) { >> // only throw exception if necessary >> if (!ignoreFailingStatusCodes) { >> throw new TestingEngineResponseException(ex.getStatusCode(), >> "unexpected status code ["+ex.getStatusCode()+"] >>at URL: ["+initialURL+"]", ex); >> } >> } catch (IOException ex) { >> throw new RuntimeException(ex); >> } >> } >> > > I have no dev env here to check but seems a good catch. Could you please fill > an issue on sourceforge? > > >>======== >> >>assertTextPresent no longer returns text inside a noframes tag - fair >>enough, my test changed. > > Probably some HtmlUnit change. Getting text in a page was notoriously > unstable feature of HtmlUnit. > > >> >>======== >> >>The following test alternately fails and succeeds when run from Eclipse: >> >> private void loginAsAdministrator() { >> gotoPage("/Admin/" + dbName + "/Main"); >> gotoFrame("admin_top"); >> clickButton("login"); >> setTextField("field_login", "_administrator_"); >> setTextField("field_password", "FIXME"); >> checkCheckbox("rememberme"); >> submit("action"); >> } >> >>I have not figured out what the problem is, but it looks like >>clickButton sometimes fails to have any effect. >>I think that this is due to a confusion between current page and current >>Frame. >> >>If I change this to >> >> private void loginAsAdministrator() { >> gotoPage("/Admin/" + dbName + "/Top"); >>// gotoFrame("admin_top"); >> clickButton("login"); >> setTextField("field_login", "_administrator_"); >> setTextField("field_password", "FIXME"); >> checkCheckbox("rememberme"); >> submit("action"); >> } >> >>it works. >>In HtmlElement.click() we have the line >> >>getPage().getWebClient().setCurrentWindow(getPage().getEnclosingWindow()); >>which I think may be the problem. >> >>A similar problem occurs when I click the link in the following, within a >>frame: >> <font face="Arial, Helvetica"> >> <a href="/melatitest/Admin/admintest/tableInfo/Main" >> target="_top" >> >> id="continue" >> >Done</a> >> >>The current page text does not change, it used to become the text of >>the _top window. >> >>I hope that this feedback is useful. >>Thanks again for a great project. > > I need to do some testing when time permits. If you want to help, try to > produce a standalone test case that I can play. > > > Thanks > > Julien > > >> >>yours >>Tim Pizey >> > > [1] http://jwebunit.sourceforge.net/building-maven.html > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > JWebUnit-users mailing list > JWebUnit-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jwebunit-users > -- Tim Pizey http://pizey.net/~timp ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ JWebUnit-users mailing list JWebUnit-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jwebunit-users
