Come utilizzare il test dell'unità? [duplicare]

Question

Come utilizzare il test dell'unità? [duplicare]

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

-4

Come usare il test dell'unità?

Esistono molti framework per lingue diverse, che forniscono funzionalità di test delle unità. Vi sono molte informazioni su come utilizzarle tecnicamente. Proprio come "importare nel tuo progetto questa lib, digitare asserire, compilare, eseguire e blah-blah-blah". Ed è tutto facile da imparare.

Il posto in cui sono confuso è come ottenerlo: quale test scrivere, per coprire una grande quantità di possibili bug?

Ad esempio, supponiamo di utilizzare jasmine framework per JS e di testare la funzione di convalida della posta elettronica.

Grande. Il nostro semplice codice sarà simile a questo:

describe("Email validation test", function() {
  it("isEmailValid(\"[email protected]\") should be true", function() {
    expect(isEmailValid("[email protected]")).toBe(true);
  });
});

Ma in realtà non abbiamo idee su come viene scritta la funzione isEmailValid e dove può fallire. Forse funziona solo se abbiamo il dominio gmail.com ? Quindi dovremmo includere un altro test con qualsiasi altro dominio.

O forse non funziona se abbiamo un dominio molto specifico, proprio come "warhammerhobbitbanachspace.am" ? In tal caso sarebbe piuttosto difficile catturare un bug. O, addirittura, impossibile.

O forse fallirà se abbiamo più di 42 simboli nella stringa con e-mail? O forse fallirà se abbiamo esattamente 9 simboli? E questa è solo una piccola quantità di esempi di luoghi che sarebbe utile testare. E questa è solo una semplice funzione di validazione delle stringhe ... E come possiamo davvero testare alcuni oggetti complessi? Sì, lo so, è impossibile testare tutto. Ma come scegliere quindi cosa dovrebbe essere realmente testato, e cosa no?

Ci sono libri o articoli che spiegano ... alcuni modelli / tecniche / principi di copertura del codice con test utili?

testing unit-testing programming-practices

posta Agafonova Victoria 27.08.2013 - 15:32

fonte

4 risposte

3

Nel caso generale, è impossibile provare la correttezza provando.

Testing shows the presence, not the absence of bug

- Dijkstra

Detto questo, puoi testare il tuo metodo con input probabili e almeno sapere che funziona e avere qualcosa con cui controllare le regressioni (vedi la risposta di Andyz). Se in seguito scopri un bug nel tuo codice, aggiungi un altro test case per quel bug in modo da sapere che almeno non incontrerai di nuovo quel problema.

risposta data 27.08.2013 - 16:02

fonte

1

Ciò che sembra cercare è il concetto di copertura del test o, più specificamente, di test unitario, copertura del codice .

Ci sono molti modi in cui puoi misurare quanto bene i tuoi test coprono il codice, dal livello molto alto, ad es. potresti dire che la tua funzione isEmailValid produce due output possibili:. tutti gli input possono essere suddivisi in due classi di equivalenza e puoi ottenere una copertura completa di tali classi testando un singolo membro di ciascuno.

Ma al test unitario è più probabile che tu voglia guardare una misura di livello più basso come copertura informativa , che sarebbe ti permette di vedere che hai testato ogni affermazione all'interno della funzione, non solo ogni output osservabile

risposta data 27.08.2013 - 15:51

fonte

1

Semplicemente scrivo il test, piuttosto che dare un'occhiata a ciò che è coperto e se non tutto è coperto, scrivo un altro test per coprire le parti mancate dai test precedenti.

Io uso TestNG perché ha qualche bella caratteristica che JUnit non ha (per es. gruppi) e che controlla la copertura con EclEmma . Entrambi i plugin funzionano bene insieme eclipse .

risposta data 27.08.2013 - 16:25

fonte

Leggi altre domande sui tag testing unit-testing programming-practices

Mi è piaciuto sviluppare un gioco 2D (C ++ SDL), ma non sono bravo in matematica / fisica [chiuso] Qual è l'importanza del multithreading per le applicazioni di rete?

score 1 · Accepted Answer

Trovo che il test delle unità sia utile in due fasi distinte e in due modelli di utilizzo distinti.

Quando si crea un nuovo codice, è difficile persino vedere se qualcosa funziona, perché il codice che si esercita o dipende dal codice non viene eseguito. Quindi, scrivi dei test unitari, che testano il tuo codice in una scatola nera. Il test presuppone che qualcuno da qualche parte chiamerà la tua funzione con parametri appropriati (in questo momento, forniti dal sistema di test unitario) e la tua funzione risponderà con una risposta appropriata, non eccezionale, non in crash, corretta. In questo modo puoi sviluppare codice in parallelo con altre attività di sistema (a volte anche in parallelo con design e architettura, ma, ahimè)
Una volta che il sistema funziona e produce un qualche tipo di valore per gli utenti o viene mostrato come un prototipo, è necessario modificare alcune infrastrutture sottostanti, come la connessione al database. In questo caso, i test di regressione sono inestimabili. Il codice di lavoro che hai in realtà ha probabilmente centinaia di ore di test perché, mentre sviluppi, esegui dei test. Una volta modificate le ipotesi sottostanti nell'infrastruttura, si perdono tutte quelle ore di test di affidabilità. È davvero utile avere un sistema di test di regressione automatizzato per rieseguire tutti quei piccoli test di unità, più e più volte, mentre si modificano alcuni parametri, come il nuovo timeout del database o gli errori di debug fondamentali nel codice di basso livello.