Looks like if we used JUnit 4, we could use methods annotated with @BeforeClass to set up fixtures that would persist between tests in a single test class. We'd get a lot of savings in classes like JSPWikiMarkupParserTest that have 200 tests, for example.
Also, I've investigated (a little) methods for reducing the need to run ResolverUtil. We would probably still need to run it at least twice: once for all of JSPWiki's needs, and once for Stripes itself. But we'd need some way of registering "interest" in particular classes to discover, so that it could all be done in one pass. I wrote the class org.apache.wiki.ui.stripes.IsOneOf exactly for this purpose (match against multiple target classes), but it's not optimized for speed yet. Andrew On Sat, Nov 28, 2009 at 5:52 PM, Andrew Jaquith <[email protected]> wrote: > Janne, I think your attachment got stripped out. Can you re-send > (maybe directly?) > > I agree that we ought to figure out some way of using some sort of > singleton (or singleton-per-wikiengine) object to stash the results of > findImplementations(). Not sure how this would work with JUnit, though > -- I should do some research. What we'd need is the ability to create > test fixture objects that persist across the entire run... > > Andrew > > On Sat, Nov 28, 2009 at 4:48 PM, Janne Jalkanen > <[email protected]> wrote: >> Folks, here's a screenshot from JProfiler. This should explain why our >> tests are fairly slow... >> >> >> >> >> >> Simply put; we're not using EhCache, and also we're calling Stripes >> ResolverUtil.findImplementations twice per WikiEngine startup. So it might >> make sense to move findImplementations() calls into a singleton or >> something. But I'm not too sure whether it makes sense considering restarts >> - or perhaps restarts should clean away the singleton cache? >> >> (This is after about 700 tests were run; I didn't want to wait until they >> had all finished, since it had already taken about two hours with profiling >> on...) >> >> Priha can be seen taking quite a lot of time as well, but that's because it >> needs to hit the disk all the time. More optimization for FileProvider is >> needed, but partly it's also because we're not caching anything. >> >> /Janne >> >
