I test unitari dovrebbero riguardare solo software "funzionale"

Stiamo utilizzando StructureMap in un nuovo progetto di sviluppo software. Uno dei membri del team ha implementato un test unitario che testa sostanzialmente la configurazione del contenitore StructureMap . Lo fa nel modo seguente;

• Conta il numero di istanze di assembly configurati per le classi nel nostro spazio dei nomi dell'applicazione.
• Definisce le istanze previste a livello di classe
• Asserisce che le istanze previste corrispondono alle istanze totali trovate.
• Asserisce che le istanze previste corrispondono a quelle definite nel test

Un esempio di questo è;

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

Abbiamo anche 'unit test' per la seguente classe;

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

In questi test, prendiamo in giro IEnvironmentRepository, quindi non lo inietteremmo dal contenitore come accadrebbe nel sistema live.

Un collega ha ignorato il test unitario sulla configurazione della strutturemap con un commento lungo la linea di "Test unitario verifica solo la propria configurazione". Questo era ovviamente lo scopo del test e secondo me è perfettamente valido. Ho chiesto al ragazzo che ha ignorato il test di rimuovere la configurazione della struttura per IEnvironmentRepository(con il test ancora ignorato) ed eseguire l'intera suite di test dell'unità, tutti hanno superato. Abbiamo quindi eseguito l'applicazione ed è caduta perché la configurazione del contenitore non era più valida. Secondo me, questo ha dimostrato il valore del test, il mio collega non era ancora d'accordo. Ha semplicemente affermato che non dovremmo testare la configurazione, ma ritengo che rientri nell'ambito di un test unitario.

Quindi una serie di domande;

• È un test unitario valido - Stiamo testando la configurazione del nostro contenitore, non che la strutturemap funzioni (ma posso vedere la sovrapposizione)
• In caso contrario, come è possibile convalidare la configurazione senza testarla. Come si può impedire a qualcuno di eliminare accidentalmente una riga di codice richiesta e archiviarla?
• Il MyClasstest unitario dovrebbe risolvere l'istanza di IEnvironmentRepositorydal contenitore e passare questo?

Questo è un test automatico perfettamente valido da avere. Li chiamo "test di architettura" in quanto verificano la solidità dei componenti scheletrici della tua base di codice.

Il contenitore IoC è in grado di risolvere e comporre tutti gli alberi degli oggetti nell'applicazione? Auto Mapper può mappare tra tutti i suoi oggetti registrati senza errori? Il livello centrale in un'architettura di cipolla non fa riferimento a qualcosa di esterno?

Questi test possono farti risparmiare molto tempo quando si verifica un bug di configurazione, indicando l'esatto colpevole. Buoni framework ti daranno messaggi di errore molto precisi su cosa c'è che non va e li ricevi non appena esegui i test (idealmente, continuamente) invece di seppellire in profondità una traccia dello stack di runtime se sei fortunato.

Che si tratti di unit test ... probabilmente no, ma funzionano ancora in memoria per la maggior parte e funzionano abbastanza velocemente. Inoltre, non lo so, non è che esistesse una definizione universalmente accettata di unit test.

Il problema con un test come questo che verifica gli interni del programma, anziché un suo requisito. È che il test può fallire anche se il programma funziona come richiesto.

Nel tuo caso, ogni volta che cambi l'impostazione del contenitore, forse hai una nuova dipendenza che deve essere iniettata, rompi il test.

Inoltre, se si aggiunge il requisito di dipendenza extra, ma si dimentica di aggiungerlo al contenitore e modificare il test del contenitore. tutto passerà, ma il tuo programma andrà in crash.

Un test automatizzato migliore sarebbe quello di avviare il programma e vedere se si blocca.

È necessario rilevare questi tipi di errore durante l'integrazione o i test dell'interfaccia utente anche se rientrano nei test unitari.

Detto questo, la crescente complessità della configurazione del contenitore è un dolore nel culo. Forse ne valgono alcuni "cattivi".

Codice test unit test. Qualunque cosa al di fuori di questo è un "altro" test automatico: chiamalo come vuoi. Sembra che tu stia testando la configurazione qui. Se la configurazione può cambiare a seconda dell'ambiente, non appartiene a un test unitario. Prendere in considerazione l'aggiunta di un attributo test per indicare che il test è di tipo diverso rispetto agli altri test.

La responsabilità del contenitore di iniezione delle dipendenze è di incollare diversi moduli in un'unica applicazione funzionante .

Se scrivi test automatici per la tua applicazione, dovresti avere pochi "test di integrazione (o accettazione) che eseguono test" da un capo all'altro ", che testeranno l'intera pipeline della tua applicazione, che tutti i moduli coinvolti in un particolare test case saranno incollati insieme correttamente .

Pertanto, tali test di integrazione falliranno se il contenitore di iniezione delle dipendenze non è stato configurato correttamente. Ciò rende inutili i test unitari per il contenitore stesso, poiché il test di integrazione dovrebbe mostrare possibili errori nella configurazione del contenitore.

Non è necessario coprire tutti i possibili casi di test nei test di integrazione, ma solo un caso di test per funzionalità che copre l'intero percorso dall'interfaccia utente al database.

Se i casi di test di integrazione non coprono l'istanza di una particolare dipendenza, è sufficiente aggiungerne una.

Con i test di integrazione è possibile cambiare liberamente i contenitori senza riscrivere i test unitari per la loro configurazione.

IMO, le risposte sono:

1. È un test unitario valido - Stiamo testando la configurazione del nostro contenitore, non che la strutturemap funzioni (ma posso vedere la sovrapposizione)

   • È un unit test valido per la strutturemap , non per il tuo progetto, perché un test unitario verifica un codice specifico, deridendo tutte le dipendenze se necessario per testare la logica implementata. La logica di configurazione è implementata all'interno di Structuremap, quindi questa libreria deve essere ben testata e deve contenere unit test come questo che hai citato, e altro: dovrebbe contenere centinaia di test come questo, deridendo dinamicamente più configurazioni in fase di esecuzione e test per vedere se il il contenitore si comporta come dovrebbe.

2. In caso contrario, come è possibile convalidare la configurazione senza testarla. Come si può impedire a qualcuno di eliminare accidentalmente una riga di codice richiesta e archiviarla?

   • Puoi testare manualmente la configurazione nell'ambiente necessario e puoi anche creare un'automazione per questo (test automatizzato), che verifica la configurazione specifica di cui hai bisogno (non c'è bisogno di deridere roba in fase di esecuzione).

3. Il test dell'unità MyClass dovrebbe risolvere l'istanza di IEnvironmentRepository dal contenitore e passarlo?

   • No, questo è un test unitario perfetto, perché deridi la dipendenza e testa la logica di MyClass in modo isolato.

UnitTest verifica il comportamento desiderato di un'unità in separazione .

Ciò significa che qualsiasi tipo di configurazione non rientra nell'ambito di UnitTest .

Tuttavia dovresti avere dei test automatici per le tue configurazioni, ma questi non sono UnitTest ...