Item 2 (fail if a page has not been tested) is not in my solution, but I'm glad I could help :-)
Regards, Daan van Etten On Wed, 2009-11-25 at 10:32 +0100, Pierre Goupil wrote: > Yeah, test coverage is a big word here. But as I said I was not looking for > a way to generate a report, just a mean to have my test suit fail if 1) a > page throws an exception at instantiation 2) a page has not been so tested. > > That's exactly what you did and I'm not surprised not to be the first one to > wonder how to achieve this. > > Of course this test is pretty basic, but as it's totally automated, that's > no big deal. You just have to know what is does and what its limits are. > Reading your blog, I see that I made the same assumptions than you regarding > that matter and that the need was the very same. > > > > > > On Wed, Nov 25, 2009 at 10:24 AM, Daan van Etten <[email protected]> wrote: > > > In my other post I gave a link to a full-fledged example which scans for > > Panel classes with the default constructor and instantiates them. > > > > > > http://stuq.nl/weblog/2009-11-01/automatically-test-your-wicket-panel-html-markup > > > > This has almost no value (in my opinion) for reporting unit testing > > coverage. It only checks for exceptions and if the code matches the > > markup at instantiation. > > An exception could easily be thrown when replacing panels, clicking on a > > link or submitting a form. This is not tested. > > > > Regards, > > > > Daan van Etten > > > > On Wed, 2009-11-25 at 10:06 +0100, Martijn Dashorst wrote: > > > Spring has a classpath scanner which you can copy and adapt to scan > > > for pages and then try to instantiate them. The problem is often that > > > pages don't have a default constructor, which is a problem if you want > > > to instantiate them automagically. > > > > > > Martijn > > > > > > On Wed, Nov 25, 2009 at 12:57 AM, Pierre Goupil <[email protected]> > > wrote: > > > > Guys, > > > > > > > > One thing that I like regarding Wicket tester is that it easily allows > > one > > > > to check a Page under design for any exception that it could throw at > > > > creation-time. Actually, doing such a basic test is for me essential, > > so as > > > > it takes only two lines of code, I systematically check all my pages > > this > > > > way. > > > > > > > > You know, the: > > > > > > > > // start and render the test page > > > > this.tester.startPage(HomePage.class); > > > > > > > > // assert rendered page class > > > > this.tester.assertRenderedPage(HomePage.class); > > > > > > > > thing. > > > > > > > > What I like so much with it is that any error which would occur when > > you > > > > load the page in FF / IE... occurs without leaving Eclipse and > > immediately. > > > > When the workflow to find the page in the browser is long and > > repetitive, > > > > it's a relief! > > > > > > > > BUT, when the number of pages grow, two related problems emerge: > > > > > > > > -you have to duplicate these two lines of code everytime, which is a > > (small) > > > > pain in itself > > > > -and you have no guarantee that you didn't forget any page, which is > > worst. > > > > > > > > So I'm looking for a way to list all Page instances in a Wicket app, > > which > > > > could then allow me to be sure that they are all covered by a test. And > > when > > > > it's done maybe I could use the same system in order to ensure that > > Selenium > > > > (the automated functional testing tool) has covered all my pages as > > well > > > > (more deeply). > > > > > > > > I could use a test coverage tool, but 1) it wouldn't work with Selenium > > 2) I > > > > don't want to generate a report, I want the test suit to fail if a Page > > is > > > > not covered by my test class. > > > > > > > > Could anyone suggest where to start, please? > > > > > > > > Regards, > > > > > > > > Pierre > > > > > > > > > > > > -- > > > > Rien de grand ne s'est accompli dans le monde sans passion. > > > > > > > > (G.W.F. Hegel, philosophe allemand) > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
