Quanto testare in TDD?

Question

Quanto testare in TDD?

#1 da (13 voti)
#2 da (6 voti)
#3 da (1 voti)

5

Sono novizio di TDD (scrivendo il primo progetto seguendo le pratiche TDD).

Ho un'interfaccia di base abbastanza IProfiler e un'implementazione Profiler .

interface IProfiler
{
  bool IsBusy {get;}
  long Elapsed {get;}
}

Un semplice test

    IProfiler profiler = default(Profiler);
    [TestInitialize]
    public void Initialize()
    {
        profiler = new Profiler();
    }

    [TestMethod]
    public void ProfilerInitializationTest()
    {
        Assert.AreEqual(false, profiler.IsBusy);
        Assert.AreEqual(true, profiler.ElapsedMilliSeconds == default(long));
    }

La domanda è: poiché avrò più stato, il numero di asserzioni aumenterà. Devo mantenere Assert separato per testare ogni campo o dovrei includere tutto qui o dovrei raggruppare in 3-4 asserti simili?

tdd unit-testing .net assertions

posta Tilak 13.01.2013 - 13:01

fonte

3 risposte

6

Dan North ha risposto a questa domanda con BDD nel 2006, questo potrebbe interessarti:

link

Per riassumere l'idea, abbiamo bisogno di un cambio di paradigma e smettiamo di pensare ai test ma più a proposito di specifiche / comportamento.

Quando scriviamo il nostro test, vogliamo prima scrivere una specifica dell'oggetto che implementeremo.

Seguendo questa filosofia scopriamo rapidamente che il nostro nome di metodi "test" dovrebbe in realtà essere una frase che descrive un comportamento previsto. Questo perché vogliamo leggere una specifica e non i test.

Vogliamo anche mantenere i nostri metodi "test" di nome breve, perché è più facile leggere e far rispettare l'idea che l'oggetto sotto specifica dovrebbe avere una Responsabilità (SRP). Ecco perché incoraggiamo l'affermazione secondo le linee guida di test.

Ad esempio, se scrivessimo una specifica per il tuo Profiler, il nome del metodo di prova potrebbe essere:

Profiler

    ShouldNotBeBusyWhenCreated

    ShouldHaveNotSpentAnyTimeInProfilingWhenCreated

Che si legge bene come una specifica. Se dovessi mettere tutte le tue affermazioni in un test, le specifiche dovrebbero essere interpretate come una frase lunga come

Profiler

    ShouldNotBeBusyAndHaveNotSpentAnyTimeInProfilingWhenCreated

Che non è molto bello, specialmente quando il test fallisce non si è in grado di capire esattamente per quale motivo non funziona.

Se torni alle tue specifiche settimane dopo, dovresti essere in grado di capire cosa l'oggetto dovrebbe fare semplicemente leggendo i nomi dei metodi "test".

risposta data 13.01.2013 - 15:13

fonte

1

non è TDD per Test Driven Development, in cui si scrive test per ottenere i requisiti descritti come test. Se parli dello stesso TDD, dovresti scrivere abbastanza test per coprire tutte le tue esigenze e non mischiarli con il test unitario, dove testare l'unità di codice piccola, ma non il requisito (ciò non significa che tu possa o non debba avere entrambi, i test unitari sono molto utili nello sviluppo).

risposta data 14.01.2013 - 18:04

fonte

Leggi altre domande sui tag tdd unit-testing .net assertions

Come vedere i bit di un intero in Visual Studio [chiuso] La riscrittura di un codice Java in C ++ usando JNI per migliorare le prestazioni è una buona idea? [chiuso]

score 13 · Accepted Answer

Attenersi ad una asserzione per test, ma non necessariamente ad una Assert.

Nella mia esperienza, il modo migliore per ottenere il giusto equilibrio, è nominare ogni metodo Dovrebbe ...

Nel tuo esempio, sarebbe ShouldInitializeWithCorrectDefaults (). Questa è una singola asserzione, indipendentemente dal numero di metodi Assert che chiamate. Non appena mi imbatto in una situazione in cui faccio fatica a non usare "E" nel nome del mio metodo, sospetto che stia testando troppo.

Inoltre, prova a tenere a mente la domanda, "se introduco un bug qui, quanti test si romperanno?" La risposta ideale (ma non sempre pratica) è 1. Presento un bug che impedisce l'inizializzazione corretta, il test ShouldInitializeWithCorrectDefaults () dovrebbe interrompersi, perché dovrebbe e ora non lo è.

Sfortunatamente, l'inizializzazione è uno di quegli esempi in cui probabilmente si romperà ogni test della classe. Il che solleva la domanda, perché preoccuparsi di testarlo da solo? A volte ci sono buone ragioni, ma spesso entri e pensi "Beh, saprò che se ogni test si interrompe, è qualcosa di comune ad ogni test, che è probabilmente un'istanza di classe, quindi ha bisogno del suo test?"