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
