Cosa c'è di sbagliato negli Stub per i test unitari?

Question

L'ho appena visto divertente Video di YouTube sui test unitari (è Hitler con sottotitoli falsi che rimprovera la sua squadra per non aver fatto buoni test unitari - saltalo se hai problemi di umorismo) dove gli stub vengono aspramente criticati.Ma non capisco cosa c'è di sbagliato negli stub.

Non ho iniziato a utilizzare un framework beffardo e non ho iniziato a sentire il dolore di non usarne uno.

Sono pronto per un mondo che soffrirà prima o poi, aver scelto matrici e falsi scritti a mano invece di mock (come Rhinomock ecc.)? (usando la tassonomia di Fowler)

Quali sono le considerazioni da fare per scegliere tra uno stub finto e uno scritto a mano?

Answer 1

Non c'è niente di sbagliato negli stub, c'è spazio per gli stub, i mock...e spie.Sono tutti "doppi test", ma con scopi diversi, come spiegato in I mock e gli stub non sono spie:

[...] Prima di andare avanti, vorrei chiarire e definire alcuni termini in uso qui, che ho scoperto originariamente in Gerard Meszaros' Modelli xUnit libro.

• Un oggetto fittizio è un oggetto segnaposto passato al sistema sottoposto a test ma mai usato.
• Un Test Stub fornisce al sistema in prova un input indiretto
• Un Test Spy fornisce un modo per verificare che il sistema sottoposto a test abbia eseguito l'uscita indiretta corretta
• Un oggetto fittizio fornisce al sistema sottoposto a test sia l'input indiretto e un modo per verificare l'output indiretto

[...] E puoi lasciare che questo pratico grafico Guida le tue decisioni:

PS: Mockito - Il nuovo framework simulato sul blocco vale anche la pena leggerlo.

Answer 2

Io uso la seguente terminologia (introdotta da Roy Osherove, l'autore dell'Arte della unit test):

A falso è chiamato stub se si dice di qualcosa di falso nel caso in cui un metodo viene chiamato con parametri tali e tali. Ma se si verifica, inoltre, che tale chiamata ha effettivamente avuto luogo o ha avuto luogo esattamente N volte, allora tale falso è chiamato finto . In breve. un falso è uno stub a meno che non si chiama Verify () su di esso e quindi si tratta di un finto.

Ovviamente, sarà necessario utilizzare stub in alcuni casi e schernisce in altri. Così, criticando aspramente stub è probabilmente sbagliato e l'utilizzo di stub esclusivamente probabilmente è sbagliato pure.

Se non hai iniziato a utilizzare un quadro beffardo (termine alternativo: quadro isolamento ), si dovrebbe tenere un occhio su di loro e rivalutare spesso le opzioni. Sono andato da deride manuali per NMock2 a Moq molto rapidamente. Ecco un interessante sondaggio di programmatori che mostra quello che uso. irride manuali / stub sono in minoranza, ma non sono così rari.

Answer 3

Mocks sono solo molto più facile da gettare in. Si tratta di una vera e propria istanza della classe, pre-stub con la possibilità di ignorare le decisioni di qualsiasi metodo con il minimo boilerplate.

Ci sono un sacco di piccoli considerazioni come: Se non si vuole affrontare con uno qualsiasi dei metodi, è possibile avere agire come un no-op o negativo il test - la vostra scelta - ma in ogni modo praticamente alcun codice.

Quanto boilerplate cosa si ottiene quando si spegnere una classe? Come si fa a gestire se la classe è definitiva? Suoni trucchi per ottenere il vostro stub sul percorso di classe prima, o si usa fonte diversa?

Vi consiglio solo a partire con i mock - E 'più facile in tutto

.

Answer 4

Non c'è niente di sbagliato con l'utilizzo di mozziconi al posto di mock.

Se si desidera ottenere tecnico, deride sono oggetti "intelligenti" con le aspettative che possono essere verificati. Mozzi sono oggetti fittizi che restituiscono valori preimpostati. Vedere Mocks Non sono stub .

Ma molte persone (me compreso) preferiscono fare il test dello stato di mozziconi, piuttosto che test comportamento con schernisce. Si inietta uno stub nella classe in prova, si chiama un metodo, quindi si controlla lo stato della classe in prova. Essa tende a rendere i test meno fragili che affermare che interni della classe denominata metodo X di un oggetto fittizio con argomento Y.

Non credo che ci si trova per un mondo di dolore. Se non si è iniziato a sentire il dolore, probabilmente non avete bisogno di un isolamento / beffardo quadro ancora. Quando e se lo fai, avendo stub scritte a mano / Falsi intorno è non andare a male a nessuno.

Se si dispone di un sacco di interfacce, o se le interfacce hanno un sacco di metodi, un isolamento / beffardo quadro possono risparmiare un sacco di tempo su stub codifica manuale.

Mi piace Moq un sacco; Trovo più facile da usare rispetto Rhino Mocks per la creazione di stub.

Answer 5

Mocks e stub viene utilizzato per ottenere un vero e proprio test di unità. Basta beffe tutte le dipendenze, e unità di prova la vostra classe in isolamento.

Attualmente sto usando MOQ per beffardo e stubbing.