standalone Jasmine vs Karma - Jasmine

Question

Sono nuovo per i test in generale e mi sono insegnato Jasmine. Sto cercando di capire le differenze tra l'esecuzione di Jasmine e jQuery-Jasmine in Karma rispetto all'esecuzione di Jasmine da solo. I tutorial per Jasmine non affrontano gli aggiustamenti che sono necessari se si utilizza Karma.

Qualcuno può spiegarmi in che modo lo standard Karma-Jasmine differisce dai requisiti del Jasmine standalone? Richiede ancora un corridore spec, e la struttura del file è sempre la stessa?

Sto testando gli eventi DOM - un sacco di gestori di clic - e non capisco come deriderlo. Qualcuno può delineare alcune idee di base? Se voglio, ad esempio, controllare che un elemento p sia stato aggiunto a un div dopo che un utente fa clic su un pulsante, come funzionerebbe nella struttura e nelle funzioni dei file?

Grazie.

Answer 1

Non ho usato jasmine-jquery, ma per i test al gelsomino con Karma, Karma usa lo karma.conf.js per scoprire dipendenze esterne (come jasmine-jquery). In particolare lo files property. Alcuni esempi sono here Se esegui test con il gelsomino con SpecRunner.html di jasmine, devi assicurarti che tutto ciò che usi sia collegato nello SpecRunner.html con i tag di script.

Come per il test dei gestori di clic, una buona scommessa potrebbe essere semplicemente chiamare direttamente le funzioni del gestore di clic. Sembra che se vuoi qualcosa di più realistico, ti stai avvicinando ai test funzionali. Per questo potresti prendere in considerazione l'integrazione di nightmare per automatizzare le interazioni degli utenti come i clic, ecc.

Answer 2

Karma e Jasmine's SpecRunner.html sono entrambi test runner (aka spec runner). La differenza tra i due è che Karma è un'applicazione che gira fuori dal browser, mentre SpecRunner è un normale file HTML con una serie di riferimenti di script che si aprono in un browser.

Un test runner che vive al di fuori del browser consente di accedere una serie di vantaggi:

• test eseguito automaticamente in one or multiple browsers in una sola volta
• automaticamente run tests on file changes, senza dover aggiornare manualmente il browser
• file di pre-processing , ovvero
  • compila da TypeScript a JavaScript prima di eseguire i test
  • modelli inline HTML in JavaScript
• file/report generation, vale a dire la copertura dei test riporta
• test framework flexibility
• facilmente includere/escludere i file di test e di origine utilizzando file and folder patterns piuttosto che cercare di disputare 100s di <script> riferimenti in un file HTML