Perché non utilizzare le domande nelle descrizioni dei test TDD [chiuso]

Question

Perché non utilizzare le domande nelle descrizioni dei test TDD [chiuso]

#1 da (5 voti)
#2 da (3 voti)

0

Sono stato un (piccolo) mentre (dieci mesi più o meno) facendo TDD per le mie applicazioni, cercando di migliorare le mie capacità seguendo questo flusso di lavoro. Quindi mi sento a mio agio nel test, nello stub, nel deridere, ecc. Ma quello che ho notato di recente è che preferisco scrivere domande anziché affermazioni nelle descrizioni dei test, ad es.

describe('library', function(){
  it('How many books does it have?', function() {
    expect(library.books).to.equal(100);
  });
});

(anziché describe('library', ... it('has 100 books'... )

Come quando il test fallisce, posso vedere il valore atteso e reale. Penso che scrivere domande faciliti il flusso di lavoro dello sviluppo dell'applicazione, poiché ciò che si tenta di codificare è dare una risposta al test. Sono consapevole che questo metodo potrebbe non essere sempre adatto, ma cosa ne pensi?

tdd testing

posta Nacho 25.03.2015 - 11:34

fonte

2 risposte

3

I test di stile BDD (come potrebbe essere il caso del framework che stai utilizzando) seguono la convenzione Given-When-Then, non la domanda-risposta. A seconda dell'approccio prescritto dalla tua libreria di test, le domande relative a questo tipo potrebbero sembrare scomode.

Tuttavia, le domande potrebbero adattarsi bene a schemi di test più classici in cui la descrizione del test è interamente contenuta nel nome del metodo di test.

Mi piace l'idea, non tanto perché tu "quello che provi a codificare è dare una risposta al test" (spesso scrivo prima la parte di asserzione del test, e l'asserzione in sostanza è la risposta), ma perché una suite di test basata su domande potrebbe leggere come una FAQ e potrebbe rendere i requisiti più facilmente comprensibili.

risposta data 25.03.2015 - 12:06

fonte

Leggi altre domande sui tag tdd testing

Un termine per descrivere il contrario di "un'estensione di una classe" App per le singole pagine e API di back-end

score 5 · Accepted Answer

Ci sono molti casi in cui si scrive un test che non è semplicemente la risposta a una domanda. Confronta 'il controller invia una mail di notifica' con 'controller dovrebbe inviare mail di notifica'. Entrambi sono validi, ma è molto più semplice leggere un elenco di test formulati come "dovrebbe" piuttosto che formulati come domande.

Un altro punto importante nel TDD è che il nome del test dovrebbe in qualche modo indicare la natura del test. 'quanti libri ha' non fa nulla per indicare perché il test è anche lì. 'il numero di libri deve essere uguale al numero di titoli moltiplicato per il numero di copie che ha' almeno ti dà qualche indicazione sul perché il test esiste e su cosa sta cercando di fare.

Tuttavia, i test, soprattutto, dovrebbero essere leggibili e consentono di individuare rapidamente gli errori. Se questo stile è vantaggioso per te e le persone che lavorano al tuo progetto vanno semplicemente avanti e usarlo.