Isolierkanne Service-Fabric ServiceContext für Unit-Tests

Question

ich eine Methode in meinem Dienst Gewebe Stateless Service-Anwendung haben, die die Konfiguration in Settings.xml von ServiceContext

public static string GetConnectionString() 
     { 
      if (context == null) 
       return string.Empty; 
      // return context.CodePackageActivationContext.GetConfigurationPackageObject("Config").Settings.Sections["MySection"].Parameters["ConnectionString"].Value; 
      ICodePackageActivationContext activationContext = context.CodePackageActivationContext; 
      ConfigurationPackage configPackage = activationContext.GetConfigurationPackageObject("Config"); 
      ConfigurationSettings configSettings = configPackage.Settings; 
      string connectionString = configSettings.Sections["ConnectionData"].Parameters["ConnectionString"].Value; 
      return connectionString; 
     }  

In dem obigen Code, den ich in viele Zeilen aufgeteilt den Code gespeichert bekommen Zum leichteren Verständnis verwende ich den kommentierten Code in meiner Anwendung.

Ich muss Komponententest für diese Methode schreiben. Ich könnte ServiceContext und ICodeActivationContext

Mock Mock Ich konnte jedoch nicht Objekte für ConfigurationSettings und ConfigurationPackage erstellen, da sie interne Konstruktoren haben.

Wie isoliere ich diese Klassen in meinem Komponententest. Oder sollte ich den Dienstkontext Teil von meinem Komponententest ausschließen.

Answer 1

Ich hatte ein fast identisches Problem mit der System.Printing PrintSystemJobInfo Klasse, es hat einen versiegelten Konstruktor, so dass es sehr schwierig war, zu verhöhnen. Ich gehe davon aus, dass Sie eine Schnittstelle erstellen, die der Klasse ähnelt, die Sie vortäuschen möchten, und erstellen Sie dann einen Wrapper für die tatsächliche Klasse, die die Schnittstelle implementiert.

Eine Lösung für Ihr Problem besteht darin, die übergeordnete Klasse als Parameter im Konstruktor der untergeordneten Klasse zu übergeben (sodass die untergeordnete Klasse Zugriff auf die übergeordneten Methoden hat und die echte Implementierung erstellen kann, die Sie umbrechen möchten).

Der folgende Code zeigt, wie ich es mit PrintSystemJobInfo gemacht habe;

using System; 
using System.Printing; 

namespace ConsoleApplication6 
{ 
class Program 
{ 
    static void Main(string[] args) 
    { 
     var server = new LocalPrintServer(); 

     IPrintQueue testablePrintQueue = new RealPrintQueue(server); 

     IPrintSystemJobInfo printSystemJobInfo = testablePrintQueue.AddJob(); 

     var result = printSystemJobInfo.IsBlocked; 

     Console.WriteLine(result); 

    } 

    public interface IPrintSystemJobInfo 
    { 
     bool IsBlocked { get; } 
    } 

    public interface IPrintQueue 
    { 
     IPrintSystemJobInfo AddJob(); 
    } 
    public class RealPrintQueue:IPrintQueue 
    { 
     private PrintQueue _queue; 
     public RealPrintQueue(LocalPrintServer server) 
     { 
      _queue = server.DefaultPrintQueue; 
     } 

     public IPrintSystemJobInfo AddJob() 
     { 
      return new RealPrintSystemJobInfo(_queue); 
     } 

    } 

    public class RealPrintSystemJobInfo: IPrintSystemJobInfo 
    { 
     private PrintSystemJobInfo job; 
     public RealPrintSystemJobInfo(PrintQueue queue) 
     { 
      job = queue.AddJob(); 
     } 

     public bool IsBlocked 
     { 
      get { return job.IsBlocked; } 
     } 
    } 
} 

}

Ich habe versucht, dies so einfach wie möglich zu halten, so habe ich nur eingewickelt IsBlocked Eigenschaft, aber man konnte es verlängern, was immer gemocht Sie (natürlich).

Answer 2

Ich würde eine Schnittstelle erstellen, die Parameter aus Service Fabric zurückgibt (eine davon ist die Verbindungszeichenfolge). Dann eine Klasse, die die Schnittstelle so implementiert, wie Sie in der Frage geschrieben haben. Und diese Schnittstelle kann verspottet im Unit-Test verwendet werden. Das Ergebnis ist - dass Sie die Methode nicht testen können, die tatsächlich von Dienstparametern liest, aber Sie können jeden, der es verwendet, mindestens testen, ohne ServiceContext und dergleichen zu mokieren.