Ich beginne gerade mit Unit-Tests und TDD im Allgemeinen. Ich habe mich schon einmal damit beschäftigt, aber jetzt bin ich entschlossen, es meinem Workflow hinzuzufügen und bessere Software zu schreiben.

Ich habe gestern eine Frage gestellt, die dies beinhaltete, aber es scheint eine Frage für sich zu sein. Ich habe mich an die Implementierung einer Serviceklasse gemacht, mit der ich die Geschäftslogik von den Controllern abstrahieren und mit EF6 bestimmten Modellen und Dateninteraktionen zuordnen kann.

Das Problem ist, dass ich mich bereits blockiert habe, weil ich EF nicht in einem Repository entfernen wollte (es wird weiterhin außerhalb der Dienste für bestimmte Abfragen usw. verfügbar sein) und meine Dienste testen möchte (EF-Kontext wird verwendet). .

Hier ist wohl die Frage, gibt es einen Grund, dies zu tun? Wenn ja, wie machen es die Leute in der Wildnis angesichts der undichten Abstraktionen, die von IQueryable und den vielen tollen Beiträgen von IQueryable verursacht werden?Ladislav Mrnka zum Thema Unit-Tests, die aufgrund der Unterschiede zwischen den Linq-Anbietern bei der Arbeit mit einer In-Memory-Implementierung für eine bestimmte Datenbank nicht einfach sind.

Der Code, den ich testen möchte, scheint ziemlich einfach zu sein. (Dies ist nur Dummy-Code, um zu verstehen, was ich tue. Ich möchte die Erstellung mit TDD vorantreiben.)

Kontext

public interface IContext
{
    IDbSet<Product> Products { get; set; }
    IDbSet<Category> Categories { get; set; }
    int SaveChanges();
}

public class DataContext : DbContext, IContext
{
    public IDbSet<Product> Products { get; set; }
    public IDbSet<Category> Categories { get; set; }

    public DataContext(string connectionString)
                : base(connectionString)
    {

    }
}

Bedienung

public class ProductService : IProductService
{
    private IContext _context;

    public ProductService(IContext dbContext)
    {
        _context = dbContext;
    }

    public IEnumerable<Product> GetAll()
    {
        var query = from p in _context.Products
                    select p;

        return query;
    }
}

Momentan bin ich in der Einstellung, ein paar Dinge zu tun:

EF Context mit so etwas wie diesem Ansatz verspotten -Verspottende EF beim Unit-Testen oder direkt ein spöttisches Framework auf der Oberfläche wie moq verwenden - den Schmerz nehmen, den die Komponententests bestehen, aber nicht notwendigerweise von Ende zu Ende arbeiten und sie mit Integrationstests unterstützen?Vielleicht mit etwas wieAnstrengung EF verspotten - Ich habe es noch nie benutzt und bin mir nicht sicher, ob es jemand in freier Wildbahn benutzt?Machen Sie sich nicht die Mühe, irgendetwas zu testen, das einfach zu EF zurückruft - also sind im Wesentlichen Dienstmethoden, die EF direkt aufrufen (getAll usw.), nicht Unit-getestet, sondern nur Integration-getestet?

Jemand da draußen, der das tatsächlich ohne Repo macht und Erfolg hat?