Come faccio ad iniettare Db in classi di servizio quando l'unità esegue il test di ServiceStack.OrmLite con NUnit?

Question

Sono interessato a scrivere test di unità (utilizzando NUnit) per alcune classi di servizio create utilizzando ServiceStack, utilizzando la "Nuova API" (che eredita da ServiceStack.ServiceInterface.Service). La proprietà Db dei servizi è correttamente auto-cablata quando è ospitata in un'applicazione ASP.NET utilizzando AppHost, ma non riesco a capire la tecnica corretta quando si esegue al di fuori di tale ambiente. Vedo una varietà di spazi dei nomi e classi di testing in ServiceStack ma non riesco a trovare un chiaro esempio di iniezione di proprietà Db di un servizio, piuttosto che impostare semplicemente un factory di connessione direttamente e quindi chiamare i vari metodi di estensione IDbConnection (Insert , Seleziona, ecc.).

ho provato avere il mio compito in classe eredita da ServiceStack.ServiceInterface.Testing.TestBase e ridefinendo il suo metodo Configura per registrare un IDbConnectionFactory (utilizzando ": la memoria:"), così come l'impostazione OrmLiteConfig.DialectProvider = SqliteDialect.Provider; nel mio TestFixtureSetUp, ma io continuo per ottenere una NullReferenceException quando si chiamano i miei metodi di servizio (su at ServiceStack.ServiceInterface.Service.get_Db()). Sembra che il contenitore Funq non stia collegando automaticamente nulla.

SQLite stesso è impostato correttamente, che sono in grado di confermare con test di unità più semplici che ignorano le mie classi di servizio e fanno semplicemente chiamate dirette IDbConnection.

Cosa mi manca?

Modifica

Sembra che i servizi di unit test ServiceStack richiede l'esistenza di un host e un cliente, anche se sembra che ci sono modi per impostare questa funzione per evitare i costi di serializzazione (utilizzando il DirectServiceClient, come mostrato here) - anche se non sono riuscito a farlo funzionare nel mio caso. Sono riuscito a farlo funzionare usando un approccio AppHostHttpListenerBase (vedi here) anche se è più un test di integrazione che un'unità uno (ed è di conseguenza più lento).

Answer 1

Il docs on Testing mostra un paio di approcci diversi per l'iniezione di dipendenze.

Se si guarda l'implementazione per la base Service solo crea l'Db dal IDbConnectionFactory:

private IDbConnection db; 
public virtual IDbConnection Db 
{ 
    get { return db ?? (db = TryResolve<IDbConnectionFactory>().OpenDbConnection()); } 
} 

che semplicemente risolve dal contenitore locale o globale IResolver CIO:

public static IResolver GlobalResolver { get; set; } 

private IResolver resolver; 
public virtual IResolver GetResolver() 
{ 
    return resolver ?? GlobalResolver; 
} 

public virtual T TryResolve<T>() 
{ 
    return this.GetResolver() == null 
     ? default(T) 
     : this.GetResolver().TryResolve<T>(); 
} 

Quindi per iniettare le proprie dipendenze (quando si utilizza la classe base di servizio) è sufficiente configurare un IAppHost con le proprie dipendenze ces bisogno che si può fare con:

using (var appHost = new BasicAppHost { 
    ConfigureContainer = c => { 
     c.Register<IDbConnectionFactory>(new ...); 
    } 
}.Init()) 
{ 
    //...  
} 

che è quindi possibile impostare sul vostro servizio insieme a qualsiasi delle proprie dipendenze vostre esigenze di servizio, ad esempio:

var service = appHost.ResolveService<MyService>(); 

Quale sarà autowire tutte le dipendenze configurate in il tuo AppHost, puoi anche aggiungere le tue dipendenze specifiche per i test ad hoc tramite normale accesso alle proprietà, e.g:

var service.MyDependency = new Mock<IMyDependency>().Object; 

Da allora in poi si può chiamare e testare i metodi di classe C# come al solito:

var response = service.Get(new RequestDto { ... }); 
Assert.That(response.Result, Is.Equal("Expected Result from DB"));