Iniettore semplice, non può ignorare la registrazione esistente

Question

Attualmente sto utilizzando Simple Injector per la prima volta. Nel mio progetto .NET Sono in esecuzione di test e dati beffardo tornato da un servizio Web e registrare l'oggetto al contenitore in questo modo

_container.Register<IWebServiceOrder>(() => mock.Object, Lifestyle.Transient); 

Questo funziona bene. Ma nei miei test voglio testare il comportamento del sistema su una seconda chiamata al servizio web che conterrà dati aggiornati, quindi l'oggetto mock dovrà essere aggiornato.

Per impostazione predefinita, Simple Injector non consente l'override delle registrazioni esistenti ma il sito Web ufficiale afferma che è possibile modificare questo comportamento come di seguito.

https://simpleinjector.readthedocs.org/en/latest/howto.html#override-existing-registrations

container.Options.AllowOverridingRegistrations = true; 

Purtroppo ancora ottengo un errore quando si tenta di registrare l'oggetto una seconda volta anche con il codice di cui sopra.

Il contenitore non può essere modificato dopo la prima chiamata a getInstance, GetAllInstances e Verifica

Tutte le idee su perché questo sta accadendo?

Answer 1

Sostituire una registrazione esistente dopo aver già lavorato con il contenitore non ha quasi mai il comportamento che ci si aspetterebbe (e ciò vale per tutte le librerie DI) e questo è il motivo per cui il contenitore Simple Injector è bloccato. Questo è descritto in ulteriori dettagli here (come già sottolineato da @qujck).

Prima di tutto, se si stanno scrivendo i test di unità, non si deve usare affatto un contenitore. Il test di unità dovrebbe creare la classe in prova se stessi, oppure estrarre questa logica ad un metodo factory pratico, come ad esempio:

private static MailNotifier CreateMailNotifier(
    IDeposit deposit = null, ISendMail mailSender = null, ILog logger = null) 
{ 
    return new MailNotifier(
     deposit ?? Substitute.For<IDeposit>(), 
     mailSender ?? Substitute.For<ISendMail>(), 
     logger ?? Substitute.For<ILog>()); 
} 

Questo metodo di fabbrica è una variante al Test Data Builder pattern.

Facendo uso di parametri opzionali, permette il test di unità per specificare solo l'attuazione falso richiede durante i test:

public void Notify_WithValidUser_LogsAMessage() 
{ 
    // Arrange 
    var user = new User(); 

    var logger = new FakeLogger(); 

    MailNotifier sut = CreateMailNotifier(logger: logger); 

    // Act 
    sut.Notify(user); 

    // Assert 
    Assert.AreEqual(expected: 1, actual: logger.LoggedMessages.Count); 
} 

Se si utilizza un contenitore, in quanto la creazione della classe in prova a mano è troppo ingombrante, indica un problema nella tua classe sotto test (molto probabilmente una violazione del Principio di Responsabilità Unica). Impedire l'utilizzo di strumenti per aggirare i problemi nella progettazione; il tuo codice ti sta parlando.

Per i test di integrazione, tuttavia, è molto più usuale utilizzare il contenitore, ma in tal caso è sufficiente creare un nuovo contenitore per ogni test di integrazione. In questo modo è possibile aggiungere o sostituire il IWebServiceOrder senza alcun problema.