W jaki sposób utrzymywać stałe ścieżki komponentów w testach jednostkowych przy korzystaniu z testera testów Wicket Tester

Question

Mam kilka testów frekwencji, które są ukierunkowane na sortowalną tabelę DataTable, w szczególności klikanie ajaxem na sortowalne nagłówki kolumn i potwierdzanie zawartości wierszy wyświetlanych brył. Teraz składnik hierarchia potomków tabeli Component jest automatycznie generowane przez ramy przejściowymi, a wyniki w ścieżkach do linków sortujących (Ajax) podobnych do:

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

Jednak gdy DataTable zostanie ponownie wygenerowana w poprzek testów indeks elementu pasków narzędzi jest zwiększany za każdym razem, czyli podobny do:

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

który następnie łamie twarde kodowane ścieżki testów kolejnych jak nie będą już takie same.

Fragment kodu dla DataTable budowy jest następująca:

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

Aby być precyzyjnym, kiedy biegnę moich testów, powyższy System.out.printf drukuje oświadczenie:

(1st testowe)

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

(2-ga 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 

(4-ty 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 

(5-ty Test)

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

Czy ktoś wie jak mogę zmusić generowanie indeksu, aby być bardziej deterministyczny/powtarzalny. Alternatywnie, czy istnieje sposób na dzikie granie w kartach lub w inny sposób uogólnianie ścieżki, aby uczynić je odpornymi na te przyrosty?

Każda pomoc będzie bardzo doceniana, chłopaki!

Answer 1

Identyfikatory są za każdym razem inkrementowane z powodu domyślnej wartości DataTableItemReuseStrategy, która generuje zupełnie nowe pozycje za każdym razem, gdy tabela jest odświeżana. Możesz mieć trochę szczęścia w implementacji niestandardowego ItemReuseStrategy, jeśli zachowanie identyfikatora jest takie samo, jest najwyższym priorytetem.

Napotkaliśmy podobny problem i uzgodniliśmy strategię dostosowaną do alternatywnego pytania. Dzięki temu możesz poprosić test o sprawdzenie np. trzeci wiersz na ostatniej renderowanej stronie. Uwaga: Kod znajduje się w Scala.

W skrócie, aby rozwiązać ten problem, zaimplementowaliśmy metodę findNthComponentOnPage w celu zwiększenia numeru 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

Ustalenie ścieżki może być dość trudne, ale nie powinno być konieczne, ponieważ składałoby się z testu integracji, a nie testu jednostkowego. Testowanie sortowania kolumny nie powinno zależeć od otaczającej tabeli, więc można utworzyć tabelę manekinów w teście dodając do testu nagłówek i jedną kolumnę (tę, która ma być posortowana). Jeśli masz obiekt paska narzędzi, możesz go użyć od razu lub odzyskać go, wydając getComponent(toolbar.getPageRelativePath()). Jednak upewnienie się, że AjaxFallbackOrderByBorder rzeczywiście działa, nie powinno stanowić problemu dla użytkownika tej klasy. Powinno to zostać zrobione przez twórcę klasy. Wystarczy przetestować swój własny kod (np. Kod sortujący w dostawcy danych) ...