Hi,
that looks fine.
I was thinking of longer tests:
- start page
- click link*
- click button*
- ...
- check table contents
(* initiating a page render)
You could put a breakpoint in RepeatingView#newChildId() and check who's
creating new items.
Have fun
Sven
On 18.03.20 12:38, Thorsten Schöning wrote:
Guten Tag Sven Meier,
am Mittwoch, 18. März 2020 um 10:04 schrieben Sie:
what IItemReuseStrategy are you using?
DefaultItemReuseStrategy creates new items on each render, which leads
to new ids.
I didn't care yet and can't find anything regarding that strategy, so
I guess it's the default one. While I indeed render the same page
multiple times within the same test, things look like the following:
try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx0))
{
VwrHtmlApp app = new VwrHtmlApp();
WicketTester tester = new WicketTester(app);
VwrHtmlPage page = new VwrPgMcsmSummary();
tester.startPage(page);
this.wicketAssertBase(tester, page);
tester.assertVisible("html:body:meterCnt.someMonth.pnMcsmSummary:resultsContainer:noResults");
tester.destroy();
}
So each invocation works with new instances of everything in theory.
Even the results to render themself change, as those are contained in
"ctx0", "ctx1" and "ctx3".
So, shouldn't each of those blocks start freshly in theory?
Mit freundlichen Grüßen,
Thorsten Schöning
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
