promesse rifiutate a goniometro/WebDriverJS

Question

WebDriverJS e goniometro si sono interamente basati sul concetto di promesse:

WebDriverJS (e quindi, goniometro) API sono del tutto asincrono. Tutte le funzioni restituiscono promesse. WebDriverJS mantiene una coda di promesse in sospeso, chiamata flusso di controllo , per mantenere organizzata l'esecuzione.

E, secondo la definition:

Una promessa è un oggetto che rappresenta un valore o l'eventuale calcolo di un valore. Ogni promessa inizia in uno stato in sospeso e può essere risolto correttamente con un valore o può essere rifiutato per designare un errore.

L'ultima parte circa il rigetto promessa è qualcosa che non capisco del tutto e non hanno affrontato in goniometro. Un modello comune che abbiamo visto e scritto è utilizzando then() e fornendo una funzione per una promessa risolto con successo:

element(by.css("#myid")).getAttribute("value").then(function (value) { 
    // do smth with the value 
}); 

la domanda:

E 'possibile che una promessa restituito da una delle goniometro/Le funzioni di WebDriverJS non verranno risolte correttamente e verrebbero rifiutate? Dovremmo davvero preoccuparci di ciò e gestirlo?

Answer 1

Ho riscontrato un caso d'uso di rifiuto della promessa durante l'utilizzo di browser.wait(). Ecco un esempio:

var EC = protractor.ExpectedConditions; 

function isElementVisible() { 

    var el = element(by.css('#myel')); 

    // return promise 
    return browser.wait(EC.visibilityOf(el), 1000) 
    .then(function success() { 
     return true; // return if promise resolved 
    }, function fail() { 
     return false; // return if promise rejected 
    }); 
} 

expect(isElementVisible()).toBe(true); 
expect(isElementVisible()).toBe(false); 

qui, se elemento è su una pagina, verrà eseguito success, altrimenti, se non viene trovato quando uno secondi passa, poi sarà chiamato fail. Il mio primo punto è che fornire un callback per il rifiuto dà la possibilità di essere coerenti con ciò che ci si dovrebbe aspettare. In questo caso sono abbastanza sicuro che la promessa verrà sempre risolta a true o false, quindi posso creare una suite basandoci su di essa. Se non fornisco un callback fail, ricevo un Uncaught exception a causa del timeout, che non funzionerà ancora con le mie specifiche particolari e gestirò comunque il resto delle specifiche.A proposito, il Goniometro lo catturerà, ma qui voglio portare un secondo punto, che Goniometro è considerato uno strumento che usi per scrivere ed eseguire il tuo codice, e se un'eccezione viene catturata dal goniometro , quindi questa eccezione ha lasciato il tuo codice non gestito e il tuo codice ha una perdita. Ma ... allo stesso tempo, non penso che si debba perdere tempo per catturare tutto nei test: se non c'è alcun elemento in una pagina o il clic non è riuscito, allora anche una rispettiva specifica fallirà, il che va bene nella maggior parte dei casi. A meno che tu non voglia usare il risultato del fallimento per costruire del codice su di esso come è nel mio esempio.

Answer 2

Questo è il bello delle promesse che otterrete una risposta, una risposta di dati o un messaggio di errore. Che si estenda ad una serie di promesse come Webdriver usa otterrai una serie di risposte o una risposta di errore del primo che fallisce. Il modo in cui gestisci la risposta fallita dipende da te. Di solito lo scarto in un log per consentire alla console di vedere cosa non funziona. L'unica cosa che devi capire è interrompere il resto dei tuoi test o continui.

Ecco un articolo decente sull'argomento. http://www.toolsqa.com/selenium-webdriver/exception-handling-selenium-webdriver/

Fyi quello che stai facendo è bene che si sta appena mai preoccuparsi di catturare uno degli errori, però, non sono sicuro se quello che conta per voi o no, si potrebbe anche astratta la chiamata in una funzione per l'auto gestire la errori per te se volessi registrarli da qualche parte.