TDD / BDD: Mock with expectations: male? [chiuso]

Hai ragione che i test dovrebbero cambiare quando l'implementazione cambia. Tuttavia, il valore dei test è che, poiché il comportamento del sistema in prova non cambia, i test saranno ancora validi. Cosa la tua classe non dovrebbe cambiare, ma come può fare la tua classe. I tuoi test ti aiuteranno quando dovrai riscrivere (una parte della) la classe.

Inoltre, 'scrivere oggetti di prova che estendono un'interfaccia comune con IS ISTITUTO (o lo stub). Solo perché non stai usando un quadro di scherno non significa che non sia un mocking.

Come nota a margine: ho visto cambiare le implementazioni perché volevamo ottimizzarle (estrarre codice comune, ridurre la complessità, ecc ...) ma non mi sono imbattuto in molte situazioni in cui un requisito mutevole causa un mucchio di test codice per diventare obsoleto, ma una classe e il suo output rimane rilevante. Pensa a O in SOLID: apri per estensione, chiuso per modifica. L'aggiunta di funzionalità o comportamenti non significa che devi sempre estrarre gli interni del codice e riscriverlo completamente.

Posso rispondere alle tue domande in modo conciso: No e no.

Uno dei principi dei buoni test è che dovrebbero essere ripetibili ( PRINCIPI principi ) quindi avere una simulazione che si comporta in modo coerente non è solo desiderabile, ma necessario.

Esistono framework di test unitari (come NUnit) che forniscono un modo per produrre chiamate N a metodi con valori casuali ma suggerirei che vengano usati con parsimonia con test ai limiti del noto i valori (o con altre regole aziendali pertinenti) preferibili.

Ovviamente c'è un posto per questi test - specialmente quando l'intervallo di valori è vasto, ma questo dovrebbe essere condotto al di fuori della solita sfera di test dell'unità (le corse di prova dovrebbero essere veloci ) - forse come test di integrazione o di ammollo.

Forse è per questo che dare mock con aspettative non è male:

• Quando l'unico scopo del SUT Foo è di manipolare altri oggetti ( X e Y ) in un certo modo.
• Scrivere mock con aspettative all'interno di un test serve come documentazione di come il SUT dovrebbe manipolare gli oggetti che chiama.

Se dovessi scrivere un test per un altro soggetto Bar che richiede il SUT di cui sopra, Foo , e hai dovuto impostare SUT con i suoi collaboratori, X e Y , non puoi preoccupati di cosa Foo fa con X e Y di essi poiché stai solo provando a testare Bar , ma potresti ancora sapere che cosa fa Foo con X e Y per dai a Bar il contesto di cui ha bisogno per essere testabile.

Anche se questo sarebbe iniziato come un test molto disordinato, offuscando lo scopo, ovvero testare Bar . In tal caso, Foo dovrebbe probabilmente essere deriso / stub / falsificato / dummio e passato a Bar .