I have several wicket tests that target a sortable DataTable, specifically ajax-clicking the sortable column headers and asserting the contents of the rendered body rows. Now the component hierarchy of the table component's descendants is auto generated by the wicket framework, and results in paths to the sorting links (ajax) similar to:
table:topToolbars:toolbars:0:headers:1:header:orderByLink
However, when the DataTable gets re-rendered across tests, the index of the toolbars component is incremented each time i.e similar to:
table:topToolbars:toolbars:1:headers:1:header:orderByLink
which then breaks the hard-coded paths of the succeeding tests as they will no longer match.
The code fragment for the datatable construction is as follows:
final PayeesProvider dataProvider = new PayeesProvider();
table = new DataTable<ResponsePayeeDetails>("payees", columns, dataProvider, rowsPerPage);
table.setOutputMarkupId(true);
table.addTopToolbar(new AjaxFallbackHeadersToolbar(table, dataProvider) {
private static final long serialVersionUID = -3509487788284410429L;
@Override
protected WebMarkupContainer newSortableHeader(final String borderId, final String property, final ISortStateLocator locator) {
return new AjaxFallbackOrderByBorder(borderId, property, locator, getAjaxCallDecorator()) {
@Override
protected void onRender() {
System.out.printf("Path: %s\n", this.getPageRelativePath());
super.onRender();
}
private static final long serialVersionUID = -6399737639959498915L;
@Override
protected void onAjaxClick(final AjaxRequestTarget target) {
target.add(getTable(), navigator, navigatorInfoContainer);
}
@Override
protected void onSortChanged() {
super.onSortChanged();
getTable().setCurrentPage(0);
}
};
}
});
table.addBottomToolbar(new NoRecordsToolbar(table));
add(table);
To be precise, when I run my tests, the above System.out.printf statement prints:
(1st test)
Path: payees:topToolbars:toolbars:0:headers:1:header
Path: payees:topToolbars:toolbars:0:headers:2:header
(2nd test)
Path: payees:topToolbars:toolbars:2:headers:1:header
Path: payees:topToolbars:toolbars:2:headers:2:header
(3rd test)
Path: payees:topToolbars:toolbars:4:headers:1:header
Path: payees:topToolbars:toolbars:4:headers:2:header
(4th test)
Path: payees:topToolbars:toolbars:6:headers:1:header
Path: payees:topToolbars:toolbars:6:headers:2:header
Path: payees:topToolbars:toolbars:6:headers:1:header
Path: payees:topToolbars:toolbars:6:headers:2:header
Path: payees:topToolbars:toolbars:6:headers:1:header
Path: payees:topToolbars:toolbars:6:headers:2:header
(5th test)
Path: payees:topToolbars:toolbars:8:headers:1:header
Path: payees:topToolbars:toolbars:8:headers:2:header
Does anyone know how I can force the index generation to be more deterministic / repeatable. Alternatively, is there a way of wild-carding or otherwise generalising the path, so as to make them immune to these increments?
Any help will be greatly appreciated chaps!
The id's are being incremented each time because of the default DataTable ItemReuseStrategy, which generates brand new items each time the table is refreshed. You may have some luck implementing a custom ItemReuseStrategy if keeping the id's the same is a top priority.
We ran into a similar issue and have settled on a strategy aligned to your alternative question. With this, you can ask the test to inspect e.g. the third row on the last rendered page. Note: Code is in Scala.
In short, to address this issue we implemented a findNthComponentOnPage method to augment the WicketTester.
/**
* @param id Wicket id of component to find
* @param n 1-based
* @tparam T class of component to find
* @return the Nth component of class T appearing on the lastRenderedPage
*/
def findNthComponentOnPage[T <: Component : ClassTag](id: String, n: Int): T = {
tester.getLastRenderedPage.visitChildren(classTag[T].runtimeClass, new IVisitor[T, T] {
var count = 0
override def component(checkbox: T, visit: IVisit[T]): Unit = {
if (checkbox.getId == id) {
count += 1
if (count == n) {
visit.stop(checkbox)
}
}
}
})
}