Qual è il valore del controllo dei test unitari guasti?

I non gradiscono le unette interrotte registrate perché producono rumore inutile. Dopo ogni unittest dovrei controllare tutti i problemi falliti (rosso). È rosso perché c'è un nuovo problema o perché c'è un vecchio open da fare / da correggere. Questo non va bene se ci sono più di 20 unittests.

Invece io uso

• % attributo di[Ignore("Reason")] che rende il risultato giallo o
• throw new NotImplementedException() che rende il risultato grigio

Nota: sto usando NUnit per .net. Non sono sicuro che la funzione "grigio" sia presente in altri framework non più validi.

Quindi mi piace il seguente significato di unit test-results.

• verde: tutto finito
• grigio: nuove funzionalità pianificate che devono essere eseguite ma con priorità bassa
• giallo: bug non ancora corretti. Dovrebbe essere risolto presto
• rosso: nuovi bug. Dovrebbe essere risolto immediatamente

Tutto tranne "rosso" può essere archiviato.

Per rispondere alla domanda: c'è più danno che valore nel check-in "red-failed-testes" ma il check-in "yellow-ignored-tests" o "gray-NotImplementedYet-tests" può essere utile come elenco di cose da fare .

Non farò finta che questo sia lo standard del settore, ma controllo i test non funzionanti come un modo per ricordare a me o ai miei altri membri del progetto che c'è ancora un problema con il codice o il test dell'unità stessa.

Suppongo che una cosa da considerare sia se le politiche di sviluppo consentano test falliti senza penalità. Ho un amico che lavora in un negozio che fa lo sviluppo basato sui test, quindi iniziano sempre con test falliti ...

I test unitari non riusciti danno al team di sviluppo la visibilità su ciò che deve essere fatto per conformarsi alle specifiche concordate.

In breve, i test unitari falliti danno al team una lista "TODO".

Per questo motivo, i test unitari falliti sono lontano migliori di nessun test unitario.

L'assenza di test unitari lascia la squadra di sviluppo al buio; le specifiche devono essere ripetutamente confermate manualmente .

[* A condizione che i test unitari in realtà testino qualcosa di utile.]

Lo scopo dei test unitari è quello di affermare il comportamento previsto di un sistema, non di documentare i difetti. Se usiamo i test unitari per documentare i difetti, viene ridotta l'utilità di questi per affermare il comportamento previsto. La risposta alla domanda "Perché questo test è fallito?" non è un semplice "Oh, qualcosa è rotto che non mi aspettavo di essere rotto". È diventato sconosciuto se l'errore del test è previsto o inaspettato.

Questo è un paragrafo dall'inizio del capitolo 13 di Funzionante in modo efficace con il codice legacy :

Automated unit tests are a very important tool, but not for bug finding--not directly, at least. In general, automated tests should specify a goal that we'd like to fulfill or attempt to preserve behavior that is already there. In the natural flow of development, tests that specify become tests that preserve. You will find bugs, but usually not the first time that a test is run. You find bugs in later runs when you change behavior that you didn't expect to.

Ma quelli guasti che identificano i bug in un nuovo progetto, nominati come tali. In questo modo puoi vedere che DOVREBBE rompere ... Mentre vengono riparati, diventano verdi e vengono spostati nella normale suite di test.

NOTA: il progetto dovrebbe essere impostato per non essere compilato sul server di build, se il server di build impedisce i check-in che interrompono la compilazione (assumendo che si definisca una build fallita come quella in cui non tutti i test passano)

I test unitari dovrebbero verificare i casi di errore oltre ai casi di successo di una funzione. Una funzione dovrebbe respingere esplicitamente l'input errato o dovrebbe avere documentazione per spiegare quale input è considerato valido.

Se hai una funzione che non sta facendo nessuna di quelle cose, è un bug e dovresti avere un modo di registrare che esiste. Creare un test unitario che dimostri questo problema è un modo per farlo. Presentare una segnalazione di bug è un'altra opzione.

Il punto di test unitario non deve avere il 100% di successo, il punto è trovare e correggere i bug nel codice. Non fare test è un modo semplice per avere il 100% di successo, ma non è molto vantaggioso per il progetto.

Presenta un bug per ogni errore e tieni presente che nel risultato del test. Quindi, se ti capita di agire insieme e correggere il bug, il test passa e lo cancelli dal risultato del test. Non ignorare i problemi.

Come vedo TDD fatto con i test di implementazione per un codice incompleto, scrivere prima i test con l'attributo [ExpectedException] o simile. Questo dovrebbe passare inizialmente in quanto il codice incompleto non avrebbe alcuna logica e scrivere un nuovo codice Exception (). Anche se l'eccezione è errata, questo non farebbe in modo che i test passassero inizialmente e fossero pronti per il check-in. Potremmo dimenticare un test ignorato, ma possiamo sicuramente riordinare o riempire il codice incompleto. Quando lo facciamo, automaticamente il test corrispondente che si aspettava un escpetion ora inizia a fallire e ti allarma a risolverlo. Ciò potrebbe comportare una leggera alterazione del test per sbarazzarsi di ExpectException e invece fare affermazioni reali. CI, Dev, tester e clienti sono tutti contenti e una situazione win-win?