unit test smell

Sto provando a cambiare i miei test unitari di ArcGIS e inizio usando i mock (io uso il rhino).
Quando ho iniziato a scrivere i test, ho notato che dovevo iniziare a deridere un sacco di oggetti, e bloccare molti metodi per far passare anche un singolo test.
Per esempio - il mio controller prima ottiene un RelationshipClass (quindi ho bisogno di stub il IWorkspace e restituita IRelationshipClass), poi si fa anche un IFeature (A stub), e, infine, chiama stubRelClass.GetRelatedObjects(stubFeature), per restituire un ISet di altri IFeatures.unit test smell

È normale dover eseguire lo stub di molti oggetti e metodi per farlo passare? Mi sento anche come ho davvero bisogno di scavalcare il codice (sì - so che avrei dovuto scrivere i test prima, sto ancora provando questo), al fine di capire che cosa spegnere fuori e cosa dovrei tornare .

Ho anche problemi con le classi com di derisione che implementano più di un'interfaccia. Nel codice di produzione I li ho tra le interfacce. Come posso creare una simulazione che implementa entrambe le interfacce in fase di runtime?

fonte

2009-06-29 Noam Gal

A seconda della catena di iniezione, sì, a volte è necessario prendere in giro molti oggetti. Tuttavia, se si approfondiscono più livelli, potrebbe essere indicativo di un errore di progettazione: gli oggetti che si basano su dati che sono tre livelli verso il basso nella propria API potrebbero non essere strettamente associati. Dovresti essere in grado di stroncare la catena sul nascere semplicemente restituendo un oggetto falso di qualche tipo ad un certo punto che ha le proprietà necessarie a cui il livello che stai testando ha bisogno.

Dovresti anche essere in grado di eseguire gran parte del tuo derisione in un metodo [SetUp] e quindi fare in modo che ogni test modifichi una o due cose.

Per il derisione di più interfacce, Rhino ha il concetto di un MultiMock. Credo che la sintassi che stai dopo è:

var mock = 
    MockRepository.DynamicMultiMock<MyType>(
       typeof(Interface1), 
       typeof(Interface2), 
       ....);

fonte

2009-06-29 06:30:18 womp

di introdurre un oggetto che taglia i livelli di profondità - si "salva" me dal beffardo alcuni più oggetti (dal momento che questo un oggetto coprirà per loro), ma mi piacerebbe ancora bisogno di prendere in giro circa la stessa quantità di metodi, giusto? O mi sto sbagliando? –

Il punto non è "salvarti" dal prendere in giro altri oggetti. Il punto è che il test sta cercando di dirti che c'è un concetto mancante, ecco perché è così complicato. –

A me suona come il codice non verificabile, che è un odore :-(

Mi raccomando di leggere http://misko.hevery.com/code-reviewers-guide/ L'autore è responsabile tecnico per l'insegnamento google. gli sviluppatori nell'area di test Nell'articolo mostra come è possibile scrivere codice verificabile e non testabile

Ulteriori letture consigliate: Codice pulito (Robert C. Martin) - l'attenzione principale su come scrivere pulito (che corrisponde a testabile) codice Funzionamento efficace con codice legacy (Michael Feather) - mostra come controllare sotto controllo il codice non verificato e non testabile.

fonte

2009-06-29 06:30:41 jens

e se non ti dispiace una breve pausa pubblicitaria ... http://www.mockobjects.com/book –

Potrebbe essere un segno di accoppiamento elevato, che a sua volta implica la necessità di ridurre le dipendenze (che miglioreranno la progettazione e la testabilità). Come linea guida approssimativa, un oggetto dovrebbe avere circa 4-6 collaboratori max. Tutto quello che avrebbe fatto scattare i miei allarmi.

How are Mocks meant to be used?

fonte

2009-06-29 06:42:25 Gishu

risposta

Problemi correlati