Un class ha un trait .
Si prevede che class chiamerà una funzione fornita da trait durante una determinata chiamata method .
Come faccio a scrivere un unit test per assicurarmi che ciò accada?
La difficoltà, secondo me, deriva dal fatto che un trait fa parte di class definition , quindi non posso prendere in giro il tratto del test, come potrei se il trait fosse invece un object passato al costruttore class .
Che cosa fa il tratto? Se il tratto cambia stato, controlla che lo stato sia stato modificato correttamente. Se il tratto recupera alcuni dati, assicurati che venga recuperato ed elaborato correttamente.
La tua unità è il metodo stesso, non il tratto da cui dipende. Tratta il tratto come un dettaglio di implementazione del metodo, poiché è quello che è.
Per i nostri scopi, questa è la stessa domanda di:
Assume I have two classes
AandB:abstract class A: method foo: 42; virtual method bar; class B extends A: method bar: self.foo() + 4;How can I unit-test class
B, considering that I cannot mockA?
Se la lingua che stai utilizzando è sufficientemente dinamica, potresti effettivamente sostituire il tipo A con una classe derisa. Se la lingua tratta i tipi come oggetti di prima classe, è possibile eseguire una forma di iniezione delle dipendenze. Altrimenti, potresti ancora utilizzare la compilazione condizionale per passare dal% effettivo diA ai test di produzione e integrazione e un simulato% diA' per il test delle unità, ma è incline a nascondere o persino a creare bug.
Ma francamente, questa complessità mi sembra sciocca. Preferisco scrivere una suite di test unitari generali per il supertipo A , che viene ereditato per ogni tipo B che in qualche modo estende , fa o implementa A . Poiché A non può essere istanziato, può essere testato da un finto B' . Successivamente, testerei gli altri sottotipi di A sia con la suite di test A, sia con i loro test individuali.
Sì, puoi sostenere che questo è un po 'un test di integrazione piuttosto che un test unitario. Tuttavia, sarebbe saggio trattare l'intero tipo con tutte le cose ereditate e tutti i tratti composti in esso come unità, al contrario delle sole parti aggiunte di recente in questa classe.
L'IMO che comprende l'UNITÀ nel test dell'unità fornirà più luce nel tuo caso
Una classe ha un carattere
Il tratto non è un oggetto
Devi testare questa classe
Per unità test questa classe le capacità pubbliche della classe sono ciò che è necessario per testare
Poiché questo è ciò che è promesso dall'implementazione di classe
Questo forma l'unità nei test a livello di unità
In sostanza significa se il tratto di quella classe
1 > Può essere proprietà pubblica (promessa come un contratto dalla classe)
2 > Può essere proprietà privata (non promessa al mondo esterno ma utilizzata esclusivamente per scopi interni)
Nel caso di 1 > cioè proprietà pubblica
È necessario affermare che la proprietà contiene informazioni sullo stato come previsto dall'autore in vari scenari, quindi scrivere test per lo stesso
Nel caso di 2 > cioè proprietà privata
IMO non ha bisogno di test.
Se tutti i metodi pubblici, i contratti come promesso dalla classe sono Asserted per funzionare come previsto in tutti gli scenari, penso che dovresti essere ben coperto.
Consegni ciò che hai promesso di offrire in tutti gli scenari come previsto.
Leggi altre domande sui tag unit-testing