Come scrivere buone descrizioni dei test di unità javascript

Question

Come scrivere buone descrizioni dei test di unità javascript

#1 da (1 voti)
#2 da (0 voti)

3

Vengo da uno sfondo di pitone. In genere, scrivo descrizioni di test di unità lunghe che collegano il test a una storia utente. Il test serve tanto a giustificare il motivo per cui il codice esiste e quanto si adatta al sistema più grande quanto a verificare la correttezza. Di conseguenza, i miei test hanno spesso tanto testo di docstring quanto il codice di test.

In javascript è più tipico utilizzare la sintassi describe e it . Qualcosa come Descrivere makeFoo - dovrebbe restituire un foo. Non vedo molte lunghe descrizioni. Questo funziona bene per TDD, ma sono meno sicuro su dove documentare perché il codice esiste in primo luogo. Perché makeFoo return foo sembra più importante di me se in realtà restituisce un foo.

Qualcuno ha consigli o esempi per ciò che rende una buona descrizione del test javascript? Devo spostare le mie storie utente al di fuori del test? Scrivili solo sui test di integrazione? Aggiungi stringhe descrittive davvero lunghe? O mi manca qualche punto in più su questo stile di test?

unit-testing javascript

posta Bufke 16.12.2017 - 19:09

fonte

2 risposte

Leggi altre domande sui tag unit-testing javascript

Come disaccoppiare il codice con la logica aziendale? WPF MVVM Caricamento dati all'avvio

score 1 · Answer 1

Nota che se sei perfettamente soddisfatto dello stile delle descrizioni che hai usato per scrivere in Python, non c'è motivo di cambiarlo. Inserisci il nome del blocco testato entro describe e inserisci la tua descrizione in it . Se è chiaro per te, non importa ciò che i progettisti del framework di test avevano in mente.

Se per qualche motivo sei infelice con il porting del tuo stile su JavaScript, quindi rimani con it('should do this or that') e appena sotto it , includi la descrizione completa:

describe('the ruler', () => {
    describe('after a double-click', () => {
        it('should reflect the cursor position instead of assuming a (0, 0)', () => {
            /**
             * The edge case documented in CAP-621 happens when a user, instead of simply
             * clicking once to position the first side of the ruler, and then click
             * another time somewhere else to fix the ruler on the page, double-clicks on
             * the page. The previous behavior was that the ruler was drawn from the cursor
             * to the (0, 0) of the page. Instead, a double-click should be treated as if
             * it was a simple click, letting the user to position the other side of the
             * ruler with another click or double-click.
             */
            ...
        });
    });
});

Durante la lettura di un test, ad esempio nel contesto in cui un cambiamento nel codice lo ha interrotto, ne capirai lo scopo semplicemente osservando il suo nome, o leggerai il lungo commento. Questo stile potrebbe anche essere preferibile ad avere solo la descrizione lunga: se il test è recente o se riguarda una parte su cui stavi lavorando di recente, è probabile che non avrai bisogno di tutta la descrizione, e avere un nome breve potrebbe salvarti tempo.

score 0 · Answer 2

Non vorrei parlare di storie utente all'interno dei commenti. Dal mio punto di vista hai un paio di modi per avvicinarti a questo:

Crea un documento di test unitario separato. Questo dovrebbe descrivere ogni test: input, comportamento previsto, asserzioni (aspettarsi (pippo) essere stringa), uscite e posizioni dei registri. Se segui questa strada puoi aggiungere quale funzione o codice sta testando il test, eventuali connessioni ad altro codice e la tua storia utente se lo desideri.

Aggiungi descrizioni di test nei commenti. Includere una descrizione, il comportamento previsto e le asserzioni. Basta tenerlo breve. Ad esempio:

describe('add new account')

 //module adds new account and include nested "describe" as needed
 describe('create new db row')...

 // specify expected behavior
 it('adds new new row in account db') ...

 //assertions
 expect 'accountid' to be integer;
 expect 'account_name' to be string; ...

(Si noti che non ho esperienza con Javascript, quindi non tutta la sintassi potrebbe essere corretta. Questo per mostrare il concetto di aggiungere descrizioni di test.)