2017-04-30 1 views
1

ich mit nightwatch.js arbeite i eine Auslagerungsdatei haben, die wie folgt aussieht:nightwatch.js behaupten auf mehrere Seitenbereiche

sections: { 
    table: { 
     selector: '.sr-filterable-data-layout--collection', 
     elements: { 
      header: { 
       selector: '.sr-collection--header' 
      }, 
      body: { 
       selector: 'sr-collection--body' 
      } 
     } 
    }, 
    filters: { 
     selector: '.sr-filterable-data-layout--filters', 
     elements: { 
      filterByName: { 
       selector: '#filter-name' 
      } 
     } 
    }, 
    actions: { 
     selector: '.sr-entities-actions', 
     elements: { 
      addButton: { 
       selector: '.mdi-content-add' 
      } 
     } 
    } 
}, 
commands: [{ 
     editEntity(options) { 
      return this.section.body(); 
     }, 
     verifyPageload() { 
      return (
       this.section.filters.waitForElementVisible('@filterByName') 
        .section.table.waitForElementVisible('@header') 
        // .section.actions.waitForElementVisible('@addButton') 
        .assert.title(this.props.title) 
      ); 
     } 
    } 
] 

auf jedes der Elemente behaupten individuell funktioniert, aber wenn ich an die Kette versuchen die Behauptungen wie folgt aus:

this.section.filters.waitForElementVisible('@filterByName') 
        .section.table.waitForElementVisible('@header') 

es mit dem folgenden Fehler fehl:

✖ TypeError: Cannot read property 'waitForElementVisible' of undefined 

jede Hilfe in Bezug auf, wie Kette diese behauptet wird zusammen viel

geschätzt werden

Antwort

1

während die Kommentare hier Möglichkeiten aufzeigen, um das Problem zu umgehen. Ich stolperte schließlich auf dem Weg zur Kette mehrere Aktionen an verschiedenen Abschnitten durch nach dem ersten Aufruf Verkettungs .parent die Wurzel der Seite zurückzukehren und nicht den Abschnitt wie folgt aus:

verifyPageload() { 
      this.section.table 
       .waitForElementVisible('@header') 
       .parent.section.filters.waitForElementVisible('@filterByName') 
       .parent.section.actions.waitForElementVisible('@addButton') 
       .assert.title(this.props.title); 
      return this; 
     } 
+0

, die äußerst umständlich erscheint, fügen Sie redundante Schritte hinzu, die von der Selenium-Sitzung ausgeführt werden (zurück zum übergeordneten Knoten), und der Code ist viel weniger lesbar. weiter - der Code ist starr und fehleranfällig: Was passiert, wenn eines der Elemente seine Position im Dom ändert? Sie müssten Ihre Tests entsprechend ändern. –

1

Sie nicht tun können, dass, wie section eine Seite Eigenschaft, während waitForElementVisible einen Verweis auf die Client-Instanz zurückgibt („Browser“), nicht auf die Seite.

Teilen Sie einfach die Befehle, es gibt wirklich keinen Grund, sie zu verketten.

Eine andere Sache; der return() Block ist hier überflüssig, nur direkt die Behauptung Ergebnis zurück:

verifyPageload() { 
    // waitForStuff... 
    return this.assert.title(this.props.title) 
} 
+0

der Grund für die Verkettung, wie ich es verstanden wurde Asynchronität. besteht die Gefahr, dass die Rücksendeaussage vor der Rückgabe erfolgt. auch, wenn ich waitForElementVisible ohne einen Abschnitt ketten; "this.element.waitForElementVisible" zueinander funktioniert es gut. – crimsonsky2005

+0

Verketten in der Nightwatch-API hat nichts zu tun mit (a) Synchronität, es ist eine Wahl in der API-Design. Die Aufrufe sind asynchron, unabhängig davon, ob sie an den Selenium-Server gesendet werden, nachdem die Nightwatch-Engine alle Ausdrücke in Ihrem Test ausgewertet hat. –

Verwandte Themen