2012-04-01 7 views
5

Quando si verifica un'eccezione nel mio test QUnit, tutto quello che voglio dire èCome ottenere QUnit per stampare il backtrace sull'eccezione?

Died on test #n: message 

Come faccio a farlo stampare un backtrace o qualche altra informazione posizione in modo che posso vedere dove si è verificata l'eccezione?

+0

Ultimo QUnit genererà linee di origine per le eccezioni che ha catturato, anche in Safari, che è comunque piuttosto brutto nella generazione di stacktraces. –

risposta

5

Non penso sia possibile fare in modo che QUnit ti indichi dove si è verificato l'errore. Il tuo codice ha generato un'eccezione, che QUnit ha rilevato e segnalato. Se spunti la casella di controllo 'notrycatch' nella parte superiore dei risultati di QUnit, i test verranno eseguiti di nuovo, ma questa volta QUnit non catturerà l'eccezione. Il tuo browser potrebbe quindi darti maggiori informazioni su cosa sia realmente accaduto, ma dipenderà dall'errore.

+0

Non sto utilizzando QUnit nel browser e non riesco a trovare la documentazione per impostare l'opzione a livello di programmazione. Sai come? –

+0

Non sono sicuro se questo è utile quando non si utilizza un browser, ma l'aggiunta di "? Notrycatch = true" all'URL è uguale a spuntare la casella di controllo. –

+4

Accetterò questa risposta perché è la più vicina. Ho capito come farlo a livello di codice: qunit.config.notrycatch = true; –

0

modifica: Mentre rispondevo a questo, il sospetto si manifestava in me che non era quello che volevi chiedere. Così ho modificato la risposta a mostrare questa, probabilmente parte più utile, in primo luogo:

Perché si scrive "Quando si verifica un'eccezione nel mio test QUnit" lascia che ti spieghi il concetto di test in un po 'più di profondità:

Prima di tutto: L'eccezione non si verifica nei test QUnit, ma nel codice. La buona notizia è: qUnit sta facendo esattamente ciò che dovrebbe fare: verifica il tuo codice e, poiché il tuo codice è difettoso, il tuo codice solleva un'eccezione durante il test.

Poiché qUnit è un ambiente di test, non è responsabile della distribuzione di trace di eccezioni. È solo lì per verificare se la funzionalità che hai implementato funziona nel modo in cui ti aspetti che funzioni, non per rintracciare i bug. Per tali scopi strumenti come FireBug o gli strumenti di sviluppo di Safari sono molto più adatti.

Permettetemi di descrivere uno scenario:

  1. si scrive una funzione
  2. si eliminano bachi da esso con (. Ie) FireBug
  3. si scrive un testcase qUnit per proove la funzione fa davvero quello che lo vuoi fare - i test passano
  4. (e ora diventa interessante, perché questo è ciò che prova è davvero per) Aggiungi qualche funzionalità aggiuntiva alla tua funzione, perché è necessario
  5. Se avete fatto tutto per bene, i test passano, e si può essere che tutto continuerà a funzionare come previsto perché fanno (se li avete scritto bene)

Riassumendo che fino: I test non sono per il debug, ma per garantire che le cose funzionino nel modo in cui pensi che funzionino. Se viene visualizzato un bug, non si scrive un test per risolverlo, ma si scrive un test per riprodurlo. Quindi trovi il bug, rimuovilo e il test passerà. Se il bug viene reinventato in seguito (ad esempio a causa di modifiche al codice), il test fallirà di nuovo, e immediatamente si saprà che il bug è tornato.

Questo può essere preso anche oltre creando uno sviluppo basato su test, in cui si scrivono test prima di scrivere la funzionalità stessa. Poi lo scenario sopra cambierebbe a questo:

  1. si scrive un test, che descrive i risultati attesi del codice
  2. si scrive il codice, quando gli insetti appaiono a rintracciare giù con (es.) Firebug
  3. mentre progredendo, un test dopo l'altro inizierà a passare
  4. quando si aggiungono ulteriori funzionalità, per la prima volta scrive ulteriore test

Ci sono due vantaggi principali in questo modo:

  1. si può essere sicuri di avere i test necessari e
  2. si è costretti a fissare esattamente ciò che si desidera che il codice per fare, perché altrimenti non è possibile scrivere i test.

Test felici.

modifica fine - la risposta originale segue, nel caso sia necessario.

Quando si utilizza QUnit che vi consiglio vivamente di seguire l'approccio indicato sul sito della documentazione di jQuery http://docs.jquery.com/Qunit:

Per utilizzare QUnit, è necessario includere i suoi qunit.js e file qunit.css e di fornire una struttura HTML di base per la visualizzazione dei risultati del test:

Tutto quello che dovete fare è caricare qunit.js e file qunit.css, poi mettere questo frammento alla tua pagina per ottenere un feedback visivo sul processo di testing:

<h1 id="qunit-header">QUnit example</h1> 
<h2 id="qunit-banner"></h2> 
<div id="qunit-testrunner-toolbar"></div> 
<h2 id="qunit-userAgent"></h2> 
<ol id="qunit-tests"></ol> 
<div id="qunit-fixture">test markup, will be hidden</div> 

Così facendo si ottiene una console nitida e interattiva che mostra rapporti esatti sui risultati del test. C'è una riga per ogni prova che mostra se è passata o meno, cliccando su quella riga spiega i risultati di ogni singolo test. Questo sarà un po 'come questo:

qUnit test results

Per personalizzare i messaggi di errore qUnit spettacoli, basta aggiungere la stringa da visualizzare per il test. Così, invece di

ok($('.testitem:first').is(':data(droppable)')) 

uso

ok($('.testitem:first').is(':data(droppable)'), 
    "testitem is droppable after calling setup_items('.testitem')"); 

per ottenere il messaggio di errore mostrato in figura. Altrimenti qUnit torna a un messaggio di errore standard associato al test utilizzato.

+1

Va bene, ma in gran parte irrilevante. La sua domanda può essere risolta con qunit.config.notrycatch = true; – aehlke

+0

interessante - peccato che si debbano cambiare "modalità" in questo modo - mi ha bloccato e molti altri sono sicuro. Mi chiedo se c'è un modo per rendere qunit fornire un supporto migliore per il processo di debug ... –

Problemi correlati