kann nicht so etwas wie TableDomainService verspotten, wo die EntityContext in der Klassendefinition gesetzt

Question

ich TDD zu lernen versuchen und zu implementieren speziell Moq und ich bin gekommen, gegen ein Design verwenden, die ich nicht herausfinden kann, wie man spottet:

namespace RIACompletelyRelativeWebService.Web.Services 
{ 
    [EnableClientAccess] 
    public class AncestorDomainService : TableDomainService<AncestorEntityContext> 
    { 
     public AncestorDomainService() 
     { 
      //this.EntityContext = new AncestorEntityContext(); 
     } 
     public IQueryable<AncestorEntity> GetAncestorEntities() 
     { 
      return this.EntityContext.AncestorEntities; 
     } 

     public void AddAncestorEntity(AncestorEntity entity) 
     { 
      this.EntityContext.AncestorEntities.Add(entity); 
     } 
    } 
} 

Ich denke, ich muss den TableDomainService verspotten, damit ich meine AncestorDomainService-Logik testen kann, ohne Azure zu starten. Ich müde etwas wie folgt aus:

public class AncestorDomainService<TEntityContext> : TableDomainService<TEntityContext> where TEntityContext is a TableEntityContext 

Aber die TableDomainService nicht wie ein Gattungswesen verwendet. Ich habe auch versucht, den EntityContext zu setzen, aber es ist nur lesbar. Ich habe gesehen, dass andere Leute das generische DomainService und das Repository-Designmuster verwenden, aber da TableDomainService es mir ermöglicht, Azure-Tabellen hinter den Kulissen zu verwenden, muss ich bei TableDomainService bleiben. <>. Muss ich nur den TableDomainService, den TableEntityContext und den TableEntitySet, der zurückgegeben wird, fälschen?

Answer 1

Ich weiß nicht aus dem Code oben, wie die Logik, die Sie testen möchten, aussieht, aber Sie könnten versuchen, Ihren Code (den Code, den Sie testen möchten) von dem Dienst selbst zu trennen.

Sie könnten versuchen, AncestorDomainService (Einführung eines IAncestorDomainService) zu abstrahieren und dann moq zum Imitieren von IAncestorDomainService zu verwenden. Ihre Logik würde in eine andere Klasse verschoben, die eine Abhängigkeit von IAncestorDomainService hat. Ich habe dies mit Linq2Sql getan (das scheint ein ähnliches Design zu haben und gibt auch IQueryable zurück). Ich würde nicht versuchen, die "Interna" von TableDomainService zu verspotten, weil diese Sachen normalerweise nicht für einfaches Testen entworfen sind.

Answer 2

Die beste Lösung, wenn Sie es sich leisten können, ist, Ihren Code vollständig testbar zu machen. Das bedeutet, dass die erforderlichen Skripts vorhanden sind, um eine Instanz von Azure (real oder lokal) mit einem bekannten guten Status einzurichten.

Da der ganze Punkt von Ihrem AncestorDomainService mit Azure zu tun hat, macht es wenig Sinn, sich über die Basisklasse lustig zu machen, wenn es um die Effektivität von Tests geht. (Manche Leute entscheiden sich dafür, die Testgeschwindigkeit gegenüber der Effektivität zu optimieren, aber ich denke, das ist Zeitverschwendung.)