2016-04-07 3 views
0

Ich habe unten eine Beispielmethode, die überprüft, ob eine Tabelle belegt ist. Es ist das erste Mal, dass ich Komponententests mache und lese, dass ein Komponententest Code nur isoliert ist und dass jede Aktion, die auf einer Datenbank ausgeführt wird, mokiert werden sollte, sonst wird es ein Integrationstest. Ich bin mir nicht ganz sicher, wie ich das ausspionieren soll, wenn mir jemand in die richtige Richtung zeigen kann.So stellen Sie eine Methode vor, die eine Verbindung mit einer MS Access-Datenbank herstellt

public bool isTableOccupied(string tableID) 
{ 
    bool tableOccupied = false; 
    try 
    { 
     connection.Open(); 
     using (OleDbCommand command = new OleDbCommand()) 
     { 
       command.Connection = connection; 
       command.CommandText = "SELECT [Occupied] FROM [Table] WHERE [TableID] [email protected]"; 
       command.Parameters.AddRange(new OleDbParameter[] { 
        new OleDbParameter("@TableID", tableID) 
        }); 
        OleDbDataReader reader = command.ExecuteReader(); 

        while (reader.Read()) 
        { 
         if (reader["Occupied"].ToString() == "True") 
         { 
          tableOccupied = true; 
         } 
        } 
      } 
      connection.Close(); 
     } 
     catch (Exception ex) 
     { 
      MessageBox.Show("Error " + ex); 
     } 
     return tableOccupied; 
} 

Antwort

1

Um ein Verfahren zur Einheit zu verspotten Testen Sie eine Schnittstelle, die Ihre Klasse implementieren, sollten zum Beispiel erstellen müssen:

public interface IRepository 
{ 
    bool IsTableOccupied(string tableId); 
} 

public class ExampleRepository : IRepository 
{ 
    public bool IsTableOccupied(string tableID) 
    { 
     // Your data access code goes here. 
    } 
} 

Zweitens sollen Sie dann „injizieren“ die Instanz die Schnittstelle in das Verfahren oder die Klasse des Muttertelefonvorwahl, zum Beispiel:

public class ExampleBusiness 
{ 
    private readonly IRepository repository; 

    public ExampleBusiness(IRepository repository) 
    { 
     this.repository = repository; 
    } 

    public bool IsTableOccupied(string tableId) 
    { 
     return this.repository.IsTableOccupied(tableId); 
    } 
} 

anschließend können Sie Unit-Tests schreiben und einen Mockframework, wie Moq, implementieren yo zu verspotten ur "isTableOccupied" -Methode, zum Beispiel:

// Create mock. 
var mockRepository = new Mock<IRepository>(); 

// Setup to return the desired mock value. In this case, return true if any string tableId is provided. 
mockRepository.Setup(x => x.IsTableOccupied(It.IsAny<string>())).Returns(true); 

// Call the parent method and inject the mock. 
var testBusiness = new ExampleBusiness(mockRepository.Object); 

// Finally, assert that the value is as expected. 
Assert.IsTrue(testBusiness.IsTableOccupied("TestId"); 
+0

Glauben Sie, dass es sich lohnt, wenn diese Methode nicht mit einer anderen Methode interagiert? Die Rückkehr hindert mich nicht daran, andere Methoden zu testen. Soll ich direkt zum Integrationstest für diese Methode gehen und den Komponententest überspringen? – user5467760

+0

Ich spotte diese Methode nur, indem ich sie in 'bool isTableOccupied (" tableID ") {return true}' ändere. Gibt es einen Punkt? – user5467760

+0

Es hängt sicherlich von jedem einzelnen Szenario ab - es lohnt sich in Ihrem Fall vielleicht nicht, aber es ist generell eine gute Methode, den Datenzugriffscode hinter einer Schnittstelle wegzuzaubern. Der Code wäre in Zukunft für Sie und andere wartbarer und testbarer. Das Beispiel, das ich gab, um wahr zu sein, war nur ein Beispiel. Sie könnten den Mock so einrichten, dass er abhängig von einer bestimmten gelieferten Id verschiedene Werte zurückgibt. Wie gesagt, jedes Szenario ist einzigartig. Ich würde sagen nur testen, ob es Mehrwert bringt und etwas lohnenswertes behauptet, oft kann ein Integrationstest sinnvoller sein. – abrown

Verwandte Themen