¿Cómo puedo mantener rutas de componentes constantes en las pruebas unitarias cuando uso Wicket Tester?

Question

Tengo varias pruebas de wicket que se dirigen a una tabla de datos clasificable, específicamente ajax-haciendo clic en los encabezados de columnas ordenables y afirmando el contenido de las filas de cuerpos representados. Ahora, la jerarquía de componentes de los descendientes del componente de tabla es generada automáticamente por el marco de ventanilla, y los resultados en los caminos a los enlaces de clasificación (Ajax) similares a:

table:topToolbars:toolbars:0:headers:1:header:orderByLink 

Sin embargo, cuando el DataTable se re-prestados a través de las pruebas, el índice de la componente de barras de herramientas se incrementa cada vez es decir, similar a:

table:topToolbars:toolbars:1:headers:1:header:orderByLink 

que luego rompe las rutas rígida de las pruebas subsiguientes ya que ya no coincidirán.

El fragmento de código para la construcción tabla de datos es el siguiente:

 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); 

Para ser más precisos, cuando corro mis pruebas, la impresora declaración anterior: System.out.printf

(primera prueba)

Path: payees:topToolbars:toolbars:0:headers:1:header 
Path: payees:topToolbars:toolbars:0:headers:2:header 

(segunda prueba)

Path: payees:topToolbars:toolbars:2:headers:1:header 
Path: payees:topToolbars:toolbars:2:headers:2:header 

(tercera prueba)

Path: payees:topToolbars:toolbars:4:headers:1:header 
Path: payees:topToolbars:toolbars:4:headers:2:header 

(cuarta prueba)

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 

(quinta prueba)

Path: payees:topToolbars:toolbars:8:headers:1:header 
Path: payees:topToolbars:toolbars:8:headers:2:header 

¿Alguien sabe cómo me puede obligar a la generación de índices a ser más determinista/repetible Alternativamente, ¿hay alguna forma de comodín o de generalizar el camino, para que sean inmunes a estos incrementos?

Cualquier ayuda será muy apreciada, ¡chicos!

Answer 1

Los identificadores se están incrementando cada vez debido al valor predeterminado DataTableItemReuseStrategy, que genera elementos nuevos cada vez que la tabla se actualiza Puede tener un poco de suerte la implementación de un ItemReuseStrategy personalizado si mantener la id es la misma es una prioridad.

Nos encontramos con un problema similar y hemos establecido una estrategia alineada a su pregunta alternativa. Con esto, puedes pedirle a la prueba que inspeccione, p. la tercera fila en la última página renderizada. Nota: El código está en Scala.

En resumen, para solucionar este problema implementamos un método findNthComponentOnPage para aumentar el 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) 
     } 

     } 
    } 
    }) 
} 

Answer 2

La determinación de la ruta puede ser bastante difícil, pero no debería ser necesaria, ya que consistiría en una prueba de integración y no en una unidad de prueba. Probar la clasificación de una columna no debe depender de la tabla que lo rodea, por lo que podría crear una tabla ficticia en su caso de prueba agregando el encabezado y una columna (la que se va a ordenar) para la prueba. Si tiene el objeto de la barra de herramientas, puede usarlo de inmediato o volver a recuperarlo emitiendo getComponent(toolbar.getPageRelativePath()). Pero asegurarse de que un AjaxFallbackOrderByBorder realmente funciona no debería ser su preocupación como usuario de esta clase. Esto debería haber sido hecho por el creador de la clase. Solo debe probar su propio código (como el código de clasificación en su proveedor de datos) ...