.pause(1000)
è davvero la migliore pratica che c'è da attendere per la presentazione del modulo? Sto cercando un modo per inviare in modo affidabile un modulo senza dover conoscere i dettagli sulla pagina che appare come risultato dell'invio del modulo.Nightwatch: modo migliore di `.pause (1000)` per evitare test fragili?
L'esempio dal home page utilizza .pause(1000)
attendere per l'invio di moduli, e per ironia della sorte non funziona più, ma questa versione con una versione css-selezione modificata fa:
Il problema con .pause(1000)
a assicurarsi che il modulo venga inviato è come determinare il timeout. È che sta andando a rendere i nostri test lenti se il timeout è troppo lungo o li rende fragili se il timeout è troppo breve. Hardware lento, altri processi sul server, allineamento lunare, il tuo nome può influenzare quali "buoni" valori di timeout dovrebbero essere.
C'è un modo migliore per dire: "Aspettare che il modulo sia inoltrato prima di continuare "?
Abbiamo sperimentato invece con .waitForElementVisible('body', VERY_LONG_TIMEOUT)
e sembra funzionare e non richiede più tempo del necessario, ma suppongo che anche questo non sia affidabile. Che funziona solo perché la pagina "corrente" è scomparsa (questa volta) e quindi stiamo aspettando che il "nuovo" corpo della pagina appaia. E che domani si verificherà qualche stranezza e sarà più veloce del normale e .waitForElementVisible('body')
tornerà immediatamente perché la vecchia pagina è ancora lì. == anche fragile. È corretto?
Se è così, c'è un modo meno fragile rispetto a .pause(1000)
o .waitForElementVisible('body')
? Soprattutto se non sappiamo molto sulla pagina restituita dopo l'invio, quindi non possiamo .waitForElementVisible('.element-only-on-new-page')
?
Il motivo che mi sto chiedendo è che i nostri test in realtà sembrava più:
module.exports = {
'Test1 - submit form' : function (client) {
client
.url('http://some/url')
.waitForElementVisible('body', 1000)
.assert.title('MyTitle')
.setValue('input[name="widget"]', 'value')
// Click to submit the form to change some internal state
.click('button[name="postForm"]')
// Form got submitted fine in chromium 42 every single time. chromium
// 45 needs additionally:
//
// .pause(1000)
// or
// .waitForElementVisible('body', 1000)
}
'Test2 - continue using new value' : function (client) {
client
.url('http://some/other/url')
.waitForElementVisible('body', 1000)
.assert.title('MyOtherTitle')
.setValue('input[name="widget2"]', 'value2')
.waitForElementVisible('.bla-bla', 1000)
}
};
Ciò ha rotto perché la forma a 'http://some/url' non viene più presentata in cromo 45 :-(Vorremmo trova una buona soluzione, non solo una che sembra funzionare in condizioni odierne ...
C'è un'idea. Mi chiedo se questo non sarà fragile in un altro modo: cosa succede se la macchina che esegue nightwatch è lenta e quelli che eseguono il selenio e il server web sono veloci. Immagino che quindi la pagina possa rinfrescarsi rapidamente, così che la chiamata '.waitForElementNotVisible()' scada. –
'
' scompare e riappare nella SPA? Funky! :-) –Forse, consiglierei di provare. Forse provare una VM e strozzarla in qualche modo? Abbiamo scoperto che Nightwatch è molto veloce nel rilevare i cambiamenti DOM. Ho adattato il codice dal nostro SPA, abbiamo un '#content div' che viene aggiornato (nascosto e mostrato) per le transizioni di pagina non il' body'. Faccio anche un controllo sul titolo per assicurarmi che sia sulla pagina giusta quando "riappare". – u02sgb