Utilizzare il contatore per testare l'accesso alla pagina non angular

Ho un'applicazione AngularJS che autentica utilizzando oAuth SSO a GitHub. Sto provando a capire un modo per utilizzare il contatore e automatizzare i test di accesso. Non riesco a capire come recuperare un field non angular e come gestire l'attesa per la pagina da caricare con browser.driver , la mia specifica è simile a questa:

 // Create a repository describe('login', function() { it('should login', function() { // this issues a redirect to GitHub browser.driver.get( process.env.HOST + '/auth/github' ) browser.sleep( 4000 ); // Sleep to make sure page loads fully.. // browser.debugger(); // tried to use debugger... var login = element( by.id( "login_field" ) ); login.sendKeys( process.env.USERNAME ); var password = element( by.id( "password" ) ); password.sendKeys( process.env.PASSWORD ) }); }); 

Ho eseguito il command come questo:

 HOST=http://someserver.com.dev USERNAME=foobar PASSWORD=barfoo protractor config/protractor.conf 

Come posso caricare correttamente la pagina di authentication, immettere le informazioni corrette nei campi e quindi attendere il reindirizzamento nella mia applicazione angolata (posso gestire le cose da lì).

Ho cercato di usare il debugger per saltare in questo codice, ma non era intuitivo per me. Quando il debugger è stato bloccato, non mi sembra di essere all'interno del mio codice, ma all'interno di cli.js. Se colpisco 'c' allora il mio script continuava fino all'esecuzione e fallì senza bloccare ulteriormente. Sono incapace di comprendere where utilizzare il command di debugger all'interno del mio script? E dal window.clientSideScripts.findInputs Chrome ho sperato di utilizzare window.clientSideScripts.findInputs ma sono stato anche bloccato; questi sembrano essere per gli elementi AngularJS, non elementi che non sono angulati.

La verifica delle pagine non angolari con il contatore può essere difficile per quanto riguarda l'attesa di roba.

Vi suggerisco di aggiornare il protrattore all'ultima (1.5.0 di adesso), usando una function personalizzata waitReady () che il browser.wait Attendi per gli elementi pronti e riscrivi il tuo test come di seguito.

 // TODO: use page objects var loginNameInputElm = $('#login_field'); // or element(by.id('login_field')) var passwordInputElm = $('#password'); // same as element(by.id('password')) var loginBtnElm = $('button[type=submit]'); it('non-angular page so ignore sync and active wait to load', function() { browser.ignoreSynchronization = true; browser.get(process.env.HOST + '/auth/github'); expect(loginNameInputElm.waitReady()).toBeTruthy(); expect(passwordInputElm.waitReady()).toBeTruthy(); }); it('should fill user and password and logins', function() { loginNameInputElm.sendKeys(process.env.USERNAME); passwordInputElm.sendKeys(process.env.PASSWORD); loginBtnElm.click(); }); it('restores ignore sync when switching back to angular pages', function() { browser.ignoreSynchronization = false; // restore browser.get('/some-angular-page'); }); 

Maggiori dettagli del perché waitReady qui .

Nota: in passato ho suggerito di impostare un livello elevato implicito, ad esempio

 browser.manage().timeouts().implicitlyWait(5000); 

Quel hack ti permette di evitare waitReady e continuare a usare lo standard

 expect(loginNameInputElm.isPresent()).toBeTruthy(); 

Ma ha uno svantaggio brutto quando si verifica un elemento NON presente, ovvero quando si effettua la verifica degli elementi assenti o non visibili, nel qual caso si aspetterà 5 secondi (5000ms) nella paletta, ad esempio quando si esegue

 expect(someNonExistingElm.isPresent()).toBeFalsy();