Hi Tom, I take all your points in consideration. Thanks again. Concerning clickRadioOption(): horrible !!! There were no unit test for this functionnality. I should definitly stop to play with Maven reports, and begin to really use them (especially Clover for unit test coverage). So I wrote a full test for all radio group relative function. clickRadioOption() seems to work perfectly, but not assertRadioOption[Not]Selected. This should now be fixed.
A new RC should be out very soon because of all this changes. ++ Julien ----- Message d'origine ---- De : Thomas Block <[EMAIL PROTECTED]> À : Usage problems for jWebUnit <[email protected]> Envoyé le : Jeudi, 18 Janvier 2007, 18h25mn 19s Objet : Re: [JWebUnit-users] [Jwebunit-users] Re : 1.4rc3 Hi Julien, finished migrating, YEAH! >Why would you use WebTestCase.getTester() method when all the public methods >of WebTester are >replicated in WebTestCase? It's just a curiosity. As Dirk pointed out, the idea is to move common test-methods to a "helper" class, e.g. TestHelper.checkNavigationBarPresent(WebTester tester) and call this from everywhere in your test suite where you would like to check for a navigation bar. The tester then contains the "context". Maybe i am just too picky about this - i always try to hide a classes fields from the user. Even in this case where we're talking about a derived class as the user. It is not really important. > FailingHttpStatusCodeException is a HtmlUnit exception. Because JWebUnit > should stay independent >of the testing engine, a new Exception is thrown : >TestingEngineResponseException (with a method >getHttpStatusCode()). >But you're right, this Exception is catched by beginAt and gotoPage, and it's >not a good idea. I >will change this, but you will have to modify your tests (just replace >FailingHttpStatusCodeException by TestingEngineResponseException). Well, not a big issue to follow those changes. Two additional things - maybe i am the only one or too stupid, but clickRadioOption(); seems to be not working. I debugged down to the HtmlUnit layer - everything seems to be OK. But when i get the form in my Struts Action, nothing happened, still default. If anyone else observed changed behaviour, please let me know - else i have to rethink my logic .... And - the testing of streaming downloads content using getPageSource()as you suggested some weeks ago: works perfectly. Again, thanks a lot, Tom >Hi Tom, > > > >>i'd suggest that you hide the tester field behind a getter-method >> >> > >Why would you use WebTestCase.getTester() method when all the public methods >of WebTester are replicated in WebTestCase? It's just a curiosity. > > > >>i'd suggest to change the overridden tearDown() to have protected access >> >> > >Good idea. > > > >>The version 1.3 threw a "FailingHttpStatusCodeException" on goto(...) >> >> > >FailingHttpStatusCodeException is a HtmlUnit exception. Because JWebUnit >should stay independent of the testing engine, a new Exception is thrown : >TestingEngineResponseException (with a method getHttpStatusCode()). >But you're right, this Exception is catched by beginAt and gotoPage, and it's >not a good idea. I will change this, but you will have to modify your tests >(just replace FailingHttpStatusCodeException by >TestingEngineResponseException). > >++ > >Julien > > >----- Message d'origine ---- >De : Tom Block <[EMAIL PROTECTED]> >À : [email protected] >Envoyé le : Mercredi, 17 Janvier 2007, 17h40mn 41s >Objet : [Jwebunit-users] 1.4rc3 > >Dear all, > >i migrated approx 80% of my tests to 1.4rc3 without any hassle - great job! > >Some little suggestions: > >Julien, you converted WebTestCase.tester to a protected field as >suggested by Dirk Jerusalem and strongly supported by myself :-). While >this is OK in terms of the functionality, i'd suggest that you hide the >tester field behind a getter-method - as it was in the 1.3 version. Just >to - hide the internal WebTestCase structure and to reduce API changes. > >Additionally, i'd suggest to change the overridden tearDown() to have >protected access. I cannot see any need to have this public. > >The version 1.3 threw a "FailingHttpStatusCodeException" on goto(...) - >which is a nice behaviour. I tested access constraints on the WebApp >using this functionality (trying to access a protected resource ended up >in a http 403 error). Version 1.4rc3 throws an AssertionFailedError - >which prevents me to distinguish between a "wanted" failure (access to >restricted areas) and a test failure. Well, i could search the exception >message - but i think it is bad programming style to explicitely catch >AssertionFailedErrors within a test case. > >After re-thinking: >the missing FailingHttpStatusCodeException lets some of my tests be >"no-tests". >original code: > >try { > gotoPage("manageSites.do"); > fail("FailingHttpStatusCodeException expected"); >} catch (FailingHttpStatusCodeException expected) { >} > >Now if i replaced FailingHttpStatusCodeException with >AssertionFailedError the test would ALWAYS run green... >So, my suggestion, keep the TestCase exceptions thrown by assertxxx() >methods and HttpErrors apart. > >Thanks a lot for your efforts, > >Tom > > > > -- ____________________________________________ Brockmann Consult Dipl.-Ing. Thomas Block Max-Planck-Str. 2 / GITZ 21502 Geesthacht Tel: +49 (0)4152 889 304 mailto:[EMAIL PROTECTED] http://www.brockmann-consult.de ____________________________________________ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ JWebUnit-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jwebunit-users ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ JWebUnit-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jwebunit-users
