Utilizzo di IoC per il test delle unità

Come può essere utilizzato un contenitore IoC per il test unitario? È utile gestire i mock in una soluzione enorme (oltre 50 progetti) utilizzando IoC? Qualche esperienza? Qualsiasi libreria C # che funzioni bene per utilizzarla nei test unitari?

In generale, un contenitore DI non dovrebbe essere necessario per il collaudo delle unità perché i test unitari riguardano esclusivamente la separazione delle responsabilità.

Considera una class che utilizza Iniezione del Costruttore

public MyClass(IMyDependency dep) { } 

Nell’intera applicazione, è ansible che ci sia un enorme grafico di dipendenza nascosto dietro IMyDependency , ma in un test unitario, si appiattisce tutto in un singolo Test Double .

È ansible utilizzare i mock dinamici come Moq o RhinoMocks per generare il Test Double, ma non è necessario.

 var dep = new Mock().Object; var sut = new MyClass(dep); 

In alcuni casi, un contenitore auto-beffardo può essere bello da avere, ma non è necessario utilizzare lo stesso contenitore DI utilizzato dall’applicazione di produzione.

Come può essere utilizzato un container Ioc per il test unitario?

IoC imporrà dei paradigmi di programmazione che renderanno le prove unitarie isolate (cioè usando i mock) più facilmente: uso di interfacce, no new (), no singleton …

Ma l’utilizzo del contenitore IoC per i test non è un requisito, ma fornirà solo alcuni servizi, ad esempio l’iniezione di mock ma è ansible farlo manualmente.

È utile gestire i mock in una soluzione enorme (oltre 50 progetti) utilizzando IoC?

Non sono sicuro di cosa intendi gestendo mock usando IoC. In ogni caso, i contenitori IoC di solito possono fare molto di più che semplicemente fare l’iniezione di mock quando si tratta di test. E se hai un supporto IDE decente che rende ansible il refactoring, perché non usarlo?

Qualche esperienza?

Sì, su una soluzione enorme, è necessaria più che mai una soluzione non soggetta a errori e di refactoring-negativo (ovvero attraverso un contenitore IoC sicuro di tipo o un buon supporto IDE).

Io uso spesso un contenitore IoC nei miei test. Certo, non sono “unit test” nel senso puro. IMO Sono più BDDish e facilitano il refactoring. I test sono lì per darti confidenza con il refactoring. Test scritti male possono essere come versare cemento nel codice.

Considera quanto segue:

 [TestFixture] public class ImageGalleryFixture : ContainerWiredFixture { [Test] public void Should_save_image() { container.ConfigureMockFor() .Setup(r => r.Create(It.IsAny())) .Verifiable(); AddToGallery(new RequestWithRealFile()); container.VerifyMockFor(); } private void AddToGallery(AddBusinessImage request) { container.Resolve().Consume(request); } } 

Ci sono diverse cose che accadono quando si aggiunge un’immagine alla galleria. L’immagine viene ridimensionata, viene generata una miniatura e i file vengono archiviati su AmazonS3. Usando un contenitore posso isolare più facilmente solo il comportamento che voglio testare, che in questo caso è la parte persistente.

Un’estensione contenitore auto-beffarda è utile quando si utilizza questa tecnica: http://www.agileatwork.com/auto-mocking-unity-container-extension/

Utilizzando container con capacità di risolvere i servizi non registrati / sconosciuti come SimpleInjector , DryIoc (il mio) può restituire mock per interfacce non ancora implementate.

Il che significa che puoi iniziare lo sviluppo con la prima implementazione semplice e le sue dipendenze burloni, e sostituirli con cose reali mentre avanzi.