2009-04-30 11 views
5

So che questo è abbastanza soggettivo, ma mi sto immergendo nei test e sto imparando a deridere e sto cercando di capire quale framework dovrei usare. Se potessi, per favore, dimmi quali sono le tue raccomandazioni e, soprattutto, perché è meglio di altre che hai usato vorrei accontentare. O se qualcuno sa dove posso ottenere un confronto side-by-side che potrebbe anche essere utile.Cercando il miglior framework di opensource per .net

+0

Per coloro che ancora lo attraversano - potrebbe anche voler considerare quali di questi framework hanno estensioni di automocking - per esempio, AutoFac e AutoFixture hanno entrambi il supporto Moq, credo che entrambi abbiano il supporto per alcuni degli altri mocking framework (Rhino, NSubstitute, ecc.). Passa un po 'di tempo nel gestore dei pacchetti anche osservando quanto sono popolari e quanto recentemente sono stati aggiornati ultimi quando si effettua una scelta. – LightCC

risposta

3

mi piace RhinoMocks, ma è l'unico che ho usato:}

Questo sembra essere molto promettente: http://code.google.com/p/mocking-frameworks-compare/

+0

C'è qualche Mi piace/Non mi piace? – Micah

+0

Scusa, non di per sé ... È stato piuttosto facile imparare e iniziare. Lo sviluppatore è estremamente attivo e rispettato nella comunità di sviluppatori. – squillman

3

Sto anche utilizzando RhinoMocks. Mi piace particolarmente il pattern AAA (Arrange-Act-Assert). RhinoMocks rende facile impostare le aspettative e controllarle utilizzando questo modello. La sintassi utilizza lambda e concatenamento, che si adatta molto bene a LINQ. La somiglianza nella sintassi aiuta a comprendere e consente al codice di essere più compatto. l'unico problema che ho con esso, e non è enorme, è che per prendere in giro un metodo deve essere virtuale. In un certo senso ciò è positivo perché "costringe" voi a rifattorizzare le interfacce, ma può essere un problema se un'interfaccia non è realmente necessaria. Può rendere più difficile il deridere alcune classi di framework. È possibile aggirare il problema contrassegnando i metodi di classe virtuali o, con classi di framework, creando un wrapper che si prende in giro. Non penso che questi problemi siano unici per RhinoMocks.

+1

Non lo sono, Moq ha le stesse "limitazioni" in quanto tutto deve essere astratto, implementare un'interfaccia o avere membri virtuali. – TheMissingLINQ

0

Ho usato NMock e penso che sia eccellente. http://www.nmock.org/

Tuttavia, questo è l'unico che ho usato.

+2

Il problema con NMock, (almeno il problema quando l'ho usato) era che tutti i nomi dei metodi erano stringhe. Ciò significa che non si ottiene alcuna guida del compilatore quando si cambiano le interfacce. Significa anche che gli strumenti di refactoring non cambieranno con successo i test. Rhino e Moq almeno non verranno compilati se si cambiano le interfacce e gli strumenti di refactoring funzionano. –

+0

Bel commento: pensa che sia tempo di guardare gli altri. – Peanut

6

Ho usato Rhino.Mocks, Moq & NMock. Preferivo Moq.

Ora uso NSubstitute ... e ho scoperto che la sua sintassi era di gran lunga superiore a quella dei moq e non sacrificare nulla con il potere.

ho usato per scrivere i test come questo:

[Test] 
public void SomeOtherTest() 
{ 
    //Arrange 
    var mock = new Mock<IFoo>(); 
    var sut = new SystemUnderTest(mock.Object); //never liked doing it this way... 
    mock.Setup(m => x.Bar()).Returns("A whole bunch of ceremonial syntax.."); 
    //Act 
    sut.DoSomething(); 
    //Assert 
    mock.Verify(m => m.Baz()); //Baaaaah, more laaaaambdas 
} 

Ora mi compiaccio per la non-lambda-eryness

[Test] 
public void NSubTest() 
{ 
    var mock = Substitute.For<IFoo>(); 
    var sut = new SystemUnderTest(mock); //much nicer! 
    mock.Bar().Returns("Look ma! No lambdas!"); 

    sut.DoSomething(); 

    mock.Received().Baz(); 
} 

punto finale .. la sua su github ...

http://nsubstitute.github.com/

Problemi correlati