Shim DbContext ctor per il test dell'unità di sforzo

Question

Shim DbContext ctor per il test dell'unità di sforzo

effort entity-framework microsoft-fakes shim unit-testing

Domanda

Mi piacerebbe intercettare var context = new MyDbContext() per restituire invece una chiamata al costruttore differente.

Il bello di EFfort è che ti permette di creare un semplice database in memoria per il test delle unità.

var connection = Effort.DbConnectionFactory.CreateTransient();
var testContext = new MyDbContext(connection);

Ma poi dovresti iniettare quel context nel tuo repository.

public FooRepository(MyDbContext context) { _context = context; }

È possibile intercettare var context = new MyDbContext() , in modo che restituisca il testContext ?

using (var context = new MyDbContext()) {
    // this way, my code isn't polluted with a ctor just for testing
}

RJB

Risposta popolare

Hai due opzioni possibili. Usando le fabbriche o tramite la programmazione orientata all'aspetto (come PostSharp)

facendo riferimento a questo articolo: http://www.progware.org/Blog/post/Interception-and-Interceptors-in-C-(Aspect-orientated-programming).aspx

Utilizzo di PostSharp (AOP)

PostSharp è un ottimo strumento e può raggiungere l'intercettazione più pulita possibile (ovvero non comporta alcuna modifica nelle classi e nella generazione di oggetti, anche se non sono le tue fabbriche per la creazione e / o l'interfaccia di oggetti) ma non è una libreria libera. Piuttosto che creare proxy in fase di runtime, esso inietta il codice in fase di compilazione e pertanto modifica il programma iniziale in modo semplice per aggiungere l'intercettazione del metodo.
.....
La cosa bella in questo è che non cambierai nient'altro nel tuo codice, quindi il tuo oggetto può ancora essere generato usando la nuova parola chiave.

Utilizzando DI e modello di fabbrica

Personalmente preferisco l'approccio del modello di fabbrica, ma sembra che tu abbia bisogno di iniettare dipendenze nelle tue classi.

public interface IDbContextFactory<T> where T : DbContext {
    T Create();
}

public class TestDbContextFactory : IDbContextFactory<MyDbContext> {
    public MyDbContext Create() {
        var connection = Effort.DbConnectionFactory.CreateTransient();
        var testContext = new MyDbContext(connection);
        return testContext;
    }
}

public class FooRepository {
    MyDbContext _context;
    public FooRepository(IDbContextFactory<MyDbContext> factory) { 
        _context = factory.Create(); 
    }
}

Nkosi

Vedi di più su Stack Overflow

Accepted Answer

(Modifica: ho appena realizzato che in realtà non sta restituendo l'altra chiamata del ctor.

Capito. Abbastanza semplice se sai come farlo:

        [TestMethod]
        public void Should_have_a_name_like_this()
        {
            // Arrange
            var connection = Effort.DbConnectionFactory.CreateTransient();
            ShimSolrDbContext.Constructor = context => new SolrDbContext(connection);

            // Act


            // Assert

        }

E come al solito, EFfort richiede questo costruttore nella classe DbContext:

public class SomeDbContext
{
    public SomeDbContext() : base("name=Prod")
    {
    }

    // EFfort unit testing ctor
    public SomeDbContext(DbConnection connection) : base(connection, contextOwnsConnection: true) {
        Database.SetInitializer<SolrDbContext>(null);
    }
}

Ma significa che il repository è beatamente inconsapevole della speciale connessione Transient:

public class SomeRepository
{
    public void SomeMethodName()
    {
        using (var context = new SomeDbContext())
        {
            // self-contained in repository, no special params
            // and still calls the special test constructor
        }
    }
}

Shim DbContext ctor per il test dell'unità di sforzo

Domanda

Fastest Entity Framework Extensions

Risposta accettata

Risposta popolare

Utilizzo di PostSharp (AOP)

Utilizzando DI e modello di fabbrica

Performance

Expression Evaluator

Related