I test delle unità stanno duplicando la logica aziendale

Question

I test delle unità stanno duplicando la logica aziendale

#1 da (4 voti)

-1

Ho

public class SomeDomainService
{
    public SomeDomainService(IDependency1 someDependency1, IDependency2 someDependency2)
    {
        // ...
    }

    public void TestableMethod(int parameter)
    {
        var result1 = this.someDependency1.Method1(parameter);
        this.someDependency2.Method2(result1);
    }
}

Sto creando un test unitario per testare SomeDomainService . Il mock di someDependency1 verrà impostato per restituire result1 e il test unitario sarà Verify (penso Moq ) che someDependency1.Method1(parameter) e che someDependency1.Method2(result1) siano stati richiamati.

Convinci che il mio test unitario non è solo una duplicazione della logica aziendale. O sto testando le cose sbagliate? Se ho torto, qual è il test unitario per SomeDomainService che si suppone test?

unit-testing

posta Hristo Yankov 05.10.2018 - 22:21

fonte

1 risposta

Leggi altre domande sui tag unit-testing

Come posso acquisire informazioni da un sito Web che non fornisce un'API? [chiuso] Come scrivere i requisiti per un modulo specifico

score 4 · Answer 1

Convince me my unit test is not just a duplication of the business logic. Or I am testing the wrong things? If I am wrong, what's the unit test for SomeDomainService supposed to test?

I materiali che vuoi recensire

467 test, 0 errori, 0 sicurezza , di Katrina Owen, ( scivoli )
Magic Tricks of Testing , di Sandi Metz, ( scivoli )

Ordina riepilogo: il metodo che stai testando qui viene invocato per i suoi effetti sugli oggetti diversi da sé . Quel caso d'uso è un po 'fuori luogo per il testing delle unità (che ama davvero le funzioni, le query sicure sugli oggetti stateful e i comandi non sicuri abbinati a query sicure su oggetti stateful).

I comandi inviati ad altri oggetti sono ... nervosi ... nei test. Tendono ad essere molto più sensibili ai dettagli di implementazione rispetto agli altri tipi. Questi tipi di test tendono ad essere più brevi rispetto alla query supportata sort

Il oggetto utile modello può aiutare a mitigare alcuni dei il rischio. Il fatto che tu stia cercando di misurare qualcosa (è stato chiamato questo metodo) potrebbe essere un odore di codice, cercando di dirti che c'è un requisito di telemetria che non hai ancora catturato. Se decidi che è giusto, sostituisci il mock con un oggetto utile (codice di produzione) che include la telemesia di cui hai bisogno, e il tuo test di unità torna al più comune ordinamento pair-a-command-and-a-query.

Ovviamente, entro i test dell'oggetto utile, tornerai nella stessa barca in cui ti trovi ora - una chiamata grezza ad un altro componente che probabilmente stai per prendere in giro. Non c'è magia, abbiamo solo mescolato l'effetto collaterale (e il mock) più lontano dal codice che stai testando.

La disciplina di base è che, man mano che ti avvicini al "confine", le implementazioni dovrebbero essere "così semplici che ovviamente non hanno carenze", a quel punto smetti di preoccuparti dei test "unità / sviluppatore", e invece sprema l'ultimo bit di fiducia usando il test di integrazione / sistema / accettazione.