Scrivi test per i test unitari in TDD?

4

In una risposta a un'altra domanda , Ho suggerito di creare un valore randomizzato per l'input su un metodo specifico. Nella mia esperienza questo è stato utile per rendere i test più leggibili e consente di saltare la "fase banale" in cui si codificano i risultati specifici in un metodo.

Ecco il codice del test unitario incollato dall'altra risposta, per un rapido riferimento:

[Test]
public void FullHouseReturnsTrue()
{
    var roll = AnyFullHouse();

    Assert.That(sut.IsFullHouse(roll));
}
[Test]
public void StraightReturnsFalse()
{
    var roll = AnyStraight();

    Assert.That(sut.IsFullHouse(roll), Is.False);
}

Un paio di commenti in risposta suggerivano che questa strategia non avrebbe funzionato bene, perché il anche il metodo di supporto dovrebbe essere testato. Nella mia esperienza, non ho mai avuto bisogno di testare metodi come questo, poiché la creazione del codice di produzione corrispondente verifica anche il mio codice di test.

Do AnyStraight() e AnyFullHouse() devono avere i propri test unitari? Se sì, come risolvi il problema di gallina e uova che presenta?

Modifica

Vorrei ancora creare test unitari dedicati per l'algoritmo AnyFullHouse se ho delineato il metodo?

[Test]
public void FullHouseReturnsTrue()
{
    var roll = listOfHardCodedFullHouseRolls[_random.Next(0, listOfHardCodedFullHouseRolls.Length)];

    Assert.That(sut.IsFullHouse(roll));
}
    
posta tallseth 07.02.2013 - 04:33
fonte

3 risposte

16

Perché randomizzare i valori? Avere campi helper di AnyStraight o AnyFullHouse con valori hardcoded è leggibile, fornisce comunque la riduzione dei valori magici, e riduce la possibilità di errore nella tua casualizzazione (oltre a garantire che il tuo i test sono ripetibili)

Nella mia esperienza, non appena i tuoi test non sono ripetibili, le persone fanno scuse sul perché falliscono. I bug effettivi vengono ignorati e i tuoi test vengono rapidamente ignorati per non rilevare gli errori. Non iniziare da questa pendenza.

    
risposta data 07.02.2013 - 05:25
fonte
5

Le suite di test come PHPUnit e JUnit, ecc., sono sviluppate usando gli stessi principi TDD (e sono generalmente testate contro se stesse).

Ovviamente, ciò significa che è necessaria una suite di bootstrap minima, ma adottando un approccio assiomatico significa che puoi facilmente creare da semplici asserzioni come "true === true" e "0! == false".

Nel tuo caso, devi semplicemente isolare gli helper e testarli - non è in realtà un pollo e un uovo, più di un inizio: devi andare più a fondo.

In alternativa, puoi supporre che gli helper siano corretti, ma in tal caso limita la tua presunta confidenza con i tuoi test, e quindi limita il loro valore.

    
risposta data 07.02.2013 - 04:47
fonte
-1

Questo è uno strano. Ho dovuto lottare con lo stesso pensiero di recente attraverso alcuni dei miei test.

Mentre dovresti davvero testare tutto ciò che scrivi, tendo ad avere una regola generale. Se è utile per l'impostazione di un test, ad esempio il raggruppamento dei metodi di configurazione per un'interfaccia usando Moq, allora no. Tuttavia, tutto il resto dovrebbe essere testato.

Quindi, in breve, penso che sarebbe necessario testare tali funzioni. Inoltre i tuoi dati generati, che potrebbero essere problematici (in più dovresti sapere esattamente quali dati passano durante il test).

    
risposta data 04.05.2017 - 08:28
fonte

Leggi altre domande sui tag