Come testare i test?

Testiamo il nostro codice per renderlo più corretto (in realtà, meno probabilità di essere errato ). Tuttavia, anche i test sono in codice: possono contenere anche errori. E se i tuoi test sono corretti, difficilmente miglioreranno il tuo codice.

Posso pensare a tre possibili tipi di errori nei test:

1. Errori logici, quando il programmatore ha frainteso il compito da svolgere e i test fanno quello che pensava di dover fare, il che è sbagliato;

2. Errori nel framework di test sottostante (es. Un'astrazione beffarda che perde);

3. Bug nei test: il test sta facendo leggermente diverso da quello che il programmatore pensa che sia.

Gli errori di tipo (1) sembrano essere impossibili da prevenire (a meno che il programmatore non diventi solo più intelligente). Tuttavia, (2) e (3) possono essere trattabili. Come gestite questi tipi di errori? Hai qualche strategia speciale per evitarli? Ad esempio, scrivi alcuni speciali test "vuoti", che controllano solo i presupposti dell'autore del test? Inoltre, come approcci il debug di un caso di test rotto?

I test sono già stati testati. I test sono protetti dalla progettazione, poiché i test rilevano solo differenze tra il codice e le nostre aspettative. Se ci sono problemi, abbiamo un errore. L'errore potrebbe essere nel codice o con la stessa probabilità nei test.

1. Esistono alcune tecniche che ti impediscono di aggiungere lo stesso bug sia nel codice che nei test:

   1. Il client dovrebbe essere una persona diversa rispetto all'implementatore.
   2. Prima scrivi i test e poi il codice (come in Test Driven Development).

2. Non è necessario testare la piattaforma sottostante. I test non solo esercitano il codice scritto da te, ma eseguono anche il codice dalla piattaforma. Sebbene non sia necessario catturare bug nella piattaforma di test, è molto difficile scrivere codice e test che nascondono sempre un bug nella piattaforma, in altre parole è molto difficile avere un bug sistematico in entrambi i test / codice e nella piattaforma e la probabilità viene ridotta con ogni test creato. Anche se provassi a farlo, avresti un compito molto difficile.

3. È possibile che si verifichino dei bug nei test, ma di solito vengono rilevati facilmente perché i test vengono testati dal codice sviluppato. Tra il codice e i test hai un feedback di auto-applicazione. Entrambi fanno previsioni su come dovrebbe comportarsi una chiamata specifica di un'interfaccia. Se la risposta è diversa, non è necessario avere un bug nel codice. Potresti avere anche un bug nel test.

Prova a rendere i singoli test il più piccolo (breve) possibile.

Ciò dovrebbe ridurre in primo luogo le possibilità di creare un bug. Anche se riesci a crearne uno, è più facile da trovare. I test unitari dovrebbero essere piccoli e specifici, con bassa tolleranza per guasti e deviazioni.

Alla fine, probabilmente è solo una questione di esperienza. Più test scrivi, migliore diventa, meno possibilità avrai di fare test scadenti.

Una tattica è scrivere il test prima del codice che verifica e assicurarsi che il test fallisca prima per la giusta ragione. Se usi TDD dovresti ottenere almeno questo livello di test dei test.

Un modo più esauriente per testare la qualità di una suite di test consiste nell'utilizzare il test di mutazione .

Per # 1 e # 3: i test unitari non devono contenere alcuna logica, se lo fai probabilmente stai testando più di una cosa nel test unitario. Una best practice per i test unitari è quella di avere un solo test per test unitario.

Guarda questo video di Roy Osherove per saperne di più su come scrivere bene i test unitari.

In termini di # 1 - Penso che sia una buona idea accoppiare / rivedere il codice per questo lato delle cose. È facile fare presupposti o semplicemente sbagliare, ma se devi spiegare cosa sta facendo il tuo test, qual è il punto, è più probabile che tu raccolga se stai mirando al bersaglio sbagliato.

Ci deve essere un punto in cui si dovrebbe smettere di provare a unit test. Dovrebbe sapere quando disegnare la linea. Dovremmo scrivere casi di test per testare casi di test? Che dire dei nuovi casi di test scritti per testare casi di test? Come li testeremo?

if (0 > printf("Hello, world\n")) {
  printf("Printing \"Hello, world\" failed\n");
}

Modifica: aggiornato con spiegazione come suggerito dal commento.

Hey.
Devi applicazioni:

• Il tuo prodotto
• Il tuo test per quel prodotto.

Quando si eseguono test sul prodotto, in realtà non si è interessati al test stesso, ma all'interazione tra il prodotto e i test. Se il test fallisce non dice che l'applicazione ha un bug. Dice che l' interazione tra prodotto e test non ha avuto successo . Ora tocca a te determinare cosa è andato storto. Può essere:

• l'applicazione non si sta comportando come previsto (questa aspettativa è espressa nel test)
• l'applicazione si sta comportando correttamente, non hai documentato correttamente questo comportamento (nei tuoi test)

Per me i test falliti non sono semplici feedback, che questo e quello sono sbagliati . È un indicatore della presenza di incoerenze e devo esaminare entrambe per verificare se il problema è andato storto. Alla fine sono responsabile della verifica che l'applicazione sia corretta, i test sono solo uno strumento per evidenziare le aree che potrebbero valere la pena di essere verificate.

I test stanno verificando solo alcune parti dell'applicazione. Collaudo l'applicazione, collaudo i test.

I test non dovrebbero essere abbastanza "intelligenti" per ospitare i bug.

Il codice che stai scrivendo implementa una serie di specifiche. (Se X allora Y, a meno che Z nel qual caso Q, ecc. Ecc.). Tutto il test che dovrebbe tentare di eseguire è determinare che X sia davvero Y a meno che Z nel qual caso Q. Ciò significa che tutto un test dovrebbe essere fatto impostando X e verificando Y.

Ma questo non copre tutti i casi, probabilmente stai dicendo, e avresti ragione. Ma se rendi il test abbastanza "intelligente" da sapere che X dovrebbe solo con Y se non Z, allora stai sostanzialmente implementando nuovamente la logica di business nel test. Questo è problematico per ragioni che approfondiremo un po 'più in basso. Non dovresti migliorare la copertura del codice rendendo il tuo primo test "più intelligente", devi invece aggiungere un secondo test stupido che imposta X e Z e verifica Q. In questo modo avrai due test, uno che copre il caso generale ( a volte noto anche come il percorso felice) e uno che copre il caso limite come un test separato.

Ci sono una serie di ragioni per questo, innanzitutto come si determina se un test fallito è dovuto a un bug nella logica aziendale o a un bug nei test? Ovviamente la risposta è che se i test sono il più semplici possibile è molto improbabile che siano presenti bug. Se ritieni che i tuoi test debbano essere testati, stai sbagliando .

Altre ragioni includono il fatto che stai solo replicando gli sforzi (come ho già detto, scrivere un test abbastanza intelligente da esercitare tutte le possibilità in un singolo test sta sostanzialmente replicando la logica aziendale che stai provando a testare in primo luogo), se i requisiti cambiano quindi i test dovrebbero essere facili da modificare per riflettere i nuovi requisiti, i test servono come una sorta di documentazione (sono un modo formale per dire quali sono le specifiche dell'unità sotto test) e così via.

TL: DR: se i tuoi test hanno bisogno di essere testati, stai sbagliando. Scrivi test stupidi .

Non una risposta (non ho il privilegio di commentare), ma mi chiedevo se hai dimenticato altri motivi per lo sviluppo di casi di test ...
Una volta individuati tutti i bug nei test, puoi regredire facilmente testando la tua applicazione. Le suite di test automatizzate ti aiuteranno a trovare i problemi prima, prima dell'integrazione. Le modifiche ai requisiti sono relativamente più facili da testare, poiché le modifiche possono diventare più recenti, versione modificata dei casi di test precedenti che passano e i casi più vecchi rimangono per raccogliere errori.

Risposta breve: il codice di produzione verifica i test .

Confronta questo con il modello di credito / debito utilizzato in economia. I meccanismi sono molto semplici: se il credito differisce dal debito, c'è qualcosa che non va.

lo stesso vale per i test unitari - Se un test fallisce indica che qualcosa non va. Potrebbe essere il codice di produzione, ma potrebbe anche essere il codice di prova! Quest'ultima parte, se importante.

Nota che i tuoi bug di tipo (1) non possono essere trovati dai test unitari. Per evitare questo tipo di bug hai bisogno di altri strumenti.