Non c'è posto per EasyMock.expect (). andReturn () nei test TDD

Question

Non c'è posto per EasyMock.expect (). andReturn () nei test TDD

#1 da (2 voti)
#2 da (-1 voti)

-1

Il TDD e le migliori pratiche generali in merito ai test di scrittura dicono che dovremmo testare il comportamento e non l'implementazione.

Ipotesi:

In that context, EasyMock.expect().andReturn() should never be used because expect().andReturn() will fail if the expected method is not called on the mocked object.

Instead, expect().andStubReturn() should be used.

Questa ipotesi è corretta?

Sto visualizzando "l'implementazione dei test" come guard rail contro i programmatori malintenzionati che si limitano a inserire codice senza test adeguati. È una cattiva pratica?

tdd testing unit-testing mocking mockups

posta kaiser 10.02.2017 - 20:41

fonte

2 risposte

Leggi altre domande sui tag tdd testing unit-testing mocking mockups

Condivisione della logica tra i servizi Come gestire l'autenticazione per le API interne ed esterne? [chiuso]

score 2 · Answer 1

La simulazione delle interazioni tra un oggetto e i suoi collaboratori pubblici non sta testando l'implementazione, ma sta testando il comportamento osservabile dell'oggetto. Solo se l'oggetto a cui stai fornendo un'implementazione fittizia è un dettaglio di implementazione interno dell'oggetto che stai testando utilizzerebbe una quantità fittizia per testare l'implementazione.

L'uso di oggetti mock è una caratteristica comune (sebbene non del tutto necessaria) di TDD. Usali quando le interazioni pubbliche tra gli oggetti sono importanti.

score -1 · Answer 2

Il comportamento dei test è l'ideale perché i test diventeranno meno fragili rispetto alle future modifiche al codice. Quando cambi il "come" e non il "cosa", preferiresti che la maggior parte del test continui a funzionare.

Invocare o inviare un messaggio ad un altro componente può essere parte del "cosa" e non significa che sei lì per l'implementazione del test.

Avendo detto che non dovresti fermarti a volte scendere ai dettagli dell'implementazione se ti aiuta a ottenere conforto nel tuo codice. Il tuo ciclo TDD è davvero più importante, a volte lo usi per scacciare l'implementazione con un test comportamentale "rosso" generale. Questo è particolarmente prezioso con algoritmi più complicati, non solo testerai il risultato finale ma anche concreti passaggi di implementazione intermedia per assicurarti di averlo fatto bene.