Wie kann ich meine verzögerte Evaluierungs-/Ausführungsfunktionalität nachahmen oder testen?

Question

Ich habe, was könnte als eine bizarre Hybrid von IQueryable<T> und IList<T> Sammlungen von Domain-Objekten gesehen, die meine Anwendung Stapel weitergegeben. Ich versuche, so viel wie möglich von der "späten Abfrage" oder "Lazy Loading" zu erhalten. Ich tue dies auf zwei Arten:

1. Durch eine LinqToSql Datenschicht unter Verwendung und Weitergabe IQueryable<T> s von Repositorys durch und meine App Schicht.
2. Dann nach meiner App Ebene IList<T> s übergeben, aber wo bestimmte Elemente in der Objekt/Aggregat-Grafik sind 'chained' with delegates, so dass ihre Belastung zu verschieben. Manchmal sind sogar die Delegierteninhalte auf IQueryable<T> Quellen angewiesen und die DataContext sind injiziert.

Das funktioniert für mich bisher.

Was blendend schwierig ist, beweist, dass dieses Design tatsächlich funktioniert. Ie. Wenn ich irgendwo den "faulen" Teil besiege und meine Bewertung/Ausführung früh stattfindet, dann ist das Ganze eine Zeitverschwendung. Ich würde das gerne irgendwie tun können.

Ich weiß nicht viel über Delegierte oder Thread-Sicherheit, da es für Delegierte gilt, die auf der gleichen Quelle handeln. Ich möchte in der Lage sein, die DataContext zu verspotten und irgendwie verfolgen beide Methoden der Verschiebung (IQueryable<T> 's SQL und die Delegierten) das Laden, so dass ich Tests haben kann, die beweisen, dass beide Funktionen auf verschiedenen Ebenen/Ebenen der App arbeiten /Stapel.

Da es entscheidend ist, dass die Verschiebung für das Design von Wert ist, würde ich gerne sehen Tests fehlschlagen, wenn ich das Design auf einer bestimmten Ebene (getrennt von der Live-Implementierung) zu brechen. Ist das möglich?

Answer 1

Bei morelinq haben wir eine so genannte "Breaking Sequence", um das zu testen. Im Grunde ist es ein Enumerator, der bei jeder Aufzählung eine Ausnahme auslöst.

Es kann so einfach sein wie:

internal sealed class BreakingSequence<T> : IEnumerable<T> 
{ 
    public IEnumerator<T> GetEnumerator() 
    { 
     throw new InvalidOperationException(); 
    } 

    IEnumerator IEnumerable.GetEnumerator() 
    { 
     return GetEnumerator(); 
    } 
} 

Ein Test für sie wie folgt aussieht:

[Test] 
    public void XyzIsLazy() 
    { 
     var source = BreakingSequence<EntityClass>().AsQueryable(); 

     // inject it as your query source wherever appropriate 
     var query = source.Where(x=> true); 
     // does not throw, where does not enumerate the sequence 
    } 

Answer 2

ich in ähnlicher Weise zu dem, was Johannes Rudolph antwortete beantworten werde. Es klingt, als ob du das Richtige denkst und einen Test für etwas Wichtiges haben willst, das schwer zu verfolgen wäre, wenn es nicht funktioniert.

Ich würde definitiv vorschlagen, einen Mock für diesen Zweck zu verwenden. Johannes schlug ein Objekt vor, das eine Ausnahme auslöst, wenn es aufgezählt wird. Da es sich bei Ihrem Objekt um ein Template handelt, sollten Sie in der Lage sein, das gewünschte Objekt zu verwenden. Ein spöttisches Framework, wie Rhino.Mocks (free) oder TypeMock Isolator (teur), kann sehr hilfreich sein. Ich empfehle dringend, in mockende Frameworks zu schauen, wenn Sie das nicht schon getan haben.

Mit einem Mock in der Hand könnten Sie auswerten, dass Operationen in einer bestimmten Reihenfolge stattfinden sollen, wenn Sie bestimmten Testcode ausführen. Sie könnten Ihren Mock programmieren, um aufzuzeichnen, welche Vorgänge stattfinden, und dann die Aufzeichnung am Ende des Tests überprüfen.