Devo scrivere test prima che vengano compilati?

Question

Ho cercato di seguire un flusso di lavoro TDD libero per uno dei miei progetti open source. È un'API per altri programmatori da utilizzare.

Come tale, un aspetto chiave oltre a far "funzionare" l'API sta anche progettando come verrà consumato. Ho sentito alcune persone dire che scrivere test prima che vengano compilati è una perdita di tempo e soggetto a riscrittura costante fino a quando l'API non è stabile. Ho anche sentito che dovrebbe seguire un flusso di lavoro in questo modo:

1. Scrivi i test, che non verrà compilato
2. Make it compilare
3. Make it verde

sono stato cercando di seguire questo flusso di lavoro, ma finisco con alcune cose strane. Ad esempio, nella mia API ho questi due metodi:

Handles(string pattern); //had this one already 
Handles(IPatternMatcher pattern); //needed this one 

Avevo bisogno di ottenere la seconda forma del metodo aggiunto alla mia API. Quindi, mi sono ritrovato con un semplice test in questo modo:

public void Handles_SupportsIPatternMatcher() 
{ 
    var api=new MyAPI(); 
    api.Handles(new TestPatternMatcher()); 
} 

Che sembra uno spreco dopo che è stato implementato.

Devo continuare a seguire questo flusso di lavoro o ci sono modi per migliorarlo? Come faccio a evitare di scrivere test che fondamentalmente controllano solo gli errori del compilatore? Poiché si tratta di un'API pubblicamente consumabile, dovrei preoccuparmi di test come questo?

Answer 1

Se si utilizza il programma di riaffilatura, è possibile creare il metodo Handles vuoto che otterrà IPatternMatcher. TDD è una cosa potente, e dovresti continuare a provare. Stavo provando entrambi i modi di test prima del codice e test dopo codice, e ho trovato che il test prima del codice è una cosa potente. È possibile eseguire il debug degli errori di codice in modo molto preciso. E il test è garanzia che il tuo codice funzionerà come previsto.

Answer 2

No.

Non scrivere codice che verifica se il compilatore sta lavorando. Quel tipo di test ha molto senso se si utilizzano linguaggi dinamici (o funzionalità dinamiche in un linguaggio statico), dove in realtà vi diranno che avete dimenticato qualcosa o refactored qualcosa in un test unitario in errore.

Il punto dell'esecuzione del test dell'unità è di fallire la build se è in errore. Se si ha un errore del compilatore nel codice, la compilazione avrà già esito negativo. Non è necessario indovinarlo.