Rhino Mock stub e mock sono utili solo per le interfacce?

Question

È corretto che stub e mock di Rhino Mocks siano utili solo per le interfacce, non per le classi concrete? Ho passato un bel po 'di tempo a cercare di far funzionare questo pezzo di codice. Non mi aspettavo che pubSubClient stoppato chiamasse sempre il metodo Send dalla classe. Questo metodo ha alcune dipendenze e genera un'eccezione.

[Test] 
public void Test01() 
{ 
    PubSubMessage psm = new PubSubMessage(); 
    var pubSubClient = MockRepository.GenerateStub<PubSubClient>(); 
    pubSubClient.Stub(x => x.Send(psm)).IgnoreArguments().Return(null); 
    // actual PubSubClient Send method throws exception 
    // the rest of the test is skipped... 
} 

Tuttavia, quando ho estratto l'interfaccia ed eseguire la stessa prova con IPubSubClient, sembra funzionare come previsto.

Significa che devo estrarre l'interfaccia per ogni classe che voglio simulare/stubare con Rhino? O mi manca qualcosa, tecnicamente o concettualmente?

UPDATE: OK, Sembra che ho capito quale parte mi mancava: Rhino Mocks non può intercettare le chiamate a metodi non-virtuali. Quindi, suppongo di aver usato le interfacce o di rendere ogni metodo sulla classe concreta virtuale. Per favore correggimi se c'è un'altra opzione.

Answer 1

La risposta di Bryan all'uso di mock parziali non è corretta. Non è per quello che servono le paroline parziali.

La risposta di Jon Erickson è in gran parte corretta: Rhino Mock e Moq non possono intercettare le chiamate non virtuali, né possono intercettare metodi o proprietà statiche. Ciò significa che non puoi fingere quanto segue:

DateTime.Now; // static property, can't fake static property 
someClass.SomeNonVirtualMethod(); // can't fake non-virtual method 
sealedClass.Foo(); // can't fake anything on sealed classes 
Utilities.SomeStaticMethod(); // can't fake static methods 
someList.Any(); // can't fake extension methods like Linq's .Any() 

TypeMock può fingere questi, come ha detto Jon.

Va notato che esiste una struttura di simulazione aggiuntiva che può intercettare tutte le chiamate: Microsoft Moles framework. Funziona allo stesso modo di TypeMock, utilizza l'API del profiler .NET per intercettare le chiamate.

Moles è gratuito (per ora). È anche beta. Moles funziona solo con Microsoft Pex tools. E la sua API è chiaramente inferiore all'API raffinata ed elegante di TypeMock.

Answer 2

Le mock parziali consentono di prendere in giro la funzionalità di una classe di calcestruzzo. Vedi: http://www.ayende.com/wiki/Rhino+Mocks+Partial+Mocks.ashx

Answer 3

Devi rendere i metodi virtuali. Rhino mocks (e la maggior parte degli altri framework di isolamento) utilizza classi proxy per creare gli stub/mock.

Se si utilizza TypeMock Isolator si può prendere in giro nulla, perché questo quadro l'isolamento utilizza .NET Profiler API al fine di creare le sue stub/deride

Answer 4

Io non credo che ci sia un altro modo di fare questo diverso da fare qualsiasi metodo tu voglia imitare virtuale - Credo che il modo in cui le mazze di classi concrete vengono create è dinamicamente sottoclassando la classe concreta che viene derisa e poi sovrascrivendo i metodi dati con il comportamento specificato nel test, quindi questo richiede un metodo virtuale per funzionare correttamente.

Answer 5

Questo è sostanzialmente corretto ed è generalmente una buona pratica. Tuttavia, è solo veramente utile per un tipo specifico di codifica.

Non pensare agli oggetti come a cose che un "potere superiore" può manipolare. Invece, pensa a loro come "persone" autonome che possono inviare messaggi a vicenda. Un'interfaccia rappresenta i messaggi inviati da un singolo oggetto.

Quindi si utilizzano i mock per verificare che siano stati inviati i messaggi corretti, non per fornire false implementazioni delle dipendenze.

Idealmente, non si crea un'interfaccia che corrisponda esattamente a una classe esistente - invece, la classe che consuma l'interfaccia dichiara le proprie esigenze sotto forma di un'interfaccia.