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] > > -- Rien de grand ne s'est accompli dans le monde sans passion. (G.W.F. Hegel, philosophe allemand)
