2016-07-27 20 views
1

Ich möchte hier beschriebene Verfahren verwenden: Automated Testing OpenXML SDK (auch hier berührt: Unit testing an application that talks to microsoft word via OpenXML)Mocking OpenXML SDK Spread

Was jedoch dauert es, das so etwas zu verspotten? Ich habe die folgende Schnittstelle gemacht:

public interface IExcelDocument 
{ 
    Row GetRow(uint rowIndex, SheetData sheetData); 
    SharedStringTablePart GetSharedStringTablePart(SpreadsheetDocument excelDoc); 
    WorksheetPart GetWorksheetPart(SpreadsheetDocument excelDoc, string sheetName); 
    Cell InsertCellInWorksheet(string columnName, uint rowIndex, WorksheetPart worksheetPart); 
    Row InsertRow(WorksheetPart worksheetPart); 
    int InsertSharedStringItem(string text, SharedStringTablePart shareStringPart); 
} 

ich so etwas wie dieses spöttische könnte mir vorstellen würde aussehen:

[TestMethod()] 
public void Excel_GetWorkseetPartTest() 
{ 
    Mock<IExcelDocument> mockExcelDocument = new Mock<IExcelDocument>(); 
    string sheetName = "sheet"; 
    var excelMock = mockExcelDocument.Object.GetWorksheetPart(MySpreadsheetDocument, sheetName); 

    Assert.IsTrue(excelMock != null); 
} 

GetWorksheetPart Methode, die ich Unit-Test wollen und in der Klasse befindet, die die Schnittstelle implementiert IExcelDocument sieht wie folgt aus:

public WorksheetPart GetWorksheetPart(SpreadsheetDocument excelDoc, string sheetName) 
{ 
    Sheet sheet = excelDoc.WorkbookPart.Workbook.Descendants<Sheet>() 
     .SingleOrDefault(s => s.Name == sheetName); 
    if (sheet == null) 
    { 
     throw new ArgumentException(
      String.Format("No sheet named {0} found in spreadsheet {1}", 
       sheetName, _filePath), "sheetName"); 
    } 
    return (WorksheetPart)excelDoc.WorkbookPart.GetPartById(sheet.Id); 
} 

ich nicht in der Lage bin herum zu wickeln MySpreadsheetDocument, weil ich müsste auch die SpreadsheetDocument.Open Methode implementieren und nicht sicher, auch wenn das vernünftig ist.

Hier ist, wie ich GetWorksheetPart nennen:

using (SpreadsheetDocument _excelDoc = SpreadsheetDocument.Open(_filePath, true)) 
{ 
    IExcelDocument excelDoc = new ExcelDocument(); 
    WorksheetPart worksheetPart = excelDoc.GetWorksheetPart(_excelDoc, sheetName); 
} 
+1

Ist Ihre Methode im Test in einer Klassenimplementierung der Schnittstelle? Ihre Formulierung ist ein wenig verwirrend – Nkosi

+0

Sie haben es richtig gemacht. –

+1

Wenn das der Fall ist, verwirren Sie das Konzept der Abstraktion Ihrer Abhängigkeiten für Ihren Komponententest. – Nkosi

Antwort

1

Sie sind verwirrend das Konzept Ihrer Abhängigkeiten für Ihr Gerät zu testen abstrahiert.

ein beispiel Klasse gegeben

public class ExcelDocument { 

    public WorksheetPart GetWorksheetPart(SpreadsheetDocument excelDoc, string sheetName) 
    { 
     Sheet sheet = excelDoc.WorkbookPart.Workbook.Descendants<Sheet>() 
      .SingleOrDefault(s => s.Name == sheetName); 
     if (sheet == null) 
     { 
      throw new ArgumentException(
       String.Format("No sheet named {0} found in spreadsheet {1}", 
        sheetName, _filePath), "sheetName"); 
     } 
     return (WorksheetPart)excelDoc.WorkbookPart.GetPartById(sheet.Id); 
    } 
} 

diese Methode ist abhängig von externer Komponente SpreadsheetDocument

SpreadsheetDocument ist das, was in diesem Fall abstrahiert werden muss.

Mit Blick auf die zu testende Methode muss die Methode in der Lage sein, eine Sheet zu bekommen, so dass Ihre Abstraktion diese Funktionalität bereitstellen muss. es muss auch in der Lage sein WorksheetPart

daraus die folgende Schnittstelle abgeleitet werden

public ISpreadsheetDocument {  
    Sheet GetSheet(string name); 
    WorksheetPart GetPartById(string id); 
} 

Dadurch ändert sich die Methode im Test auf diese

public WorksheetPart GetWorksheetPart(ISpreadsheetDocument excelDoc, string sheetName) 
{ 
    Sheet sheet = excelDoc.GetSheet(sheetName); 
    if (sheet == null) 
    { 
     throw new ArgumentException(
      String.Format("No sheet named {0} found in spreadsheet {1}", 
       sheetName, _filePath), "sheetName"); 
    } 
    return excelDoc.GetPartById(sheet.Id); 
} 

Sie können jetzt das Mock/fack kann zu bekommen excelDoc, wenn es für Ihre Komponententests benötigt wird und Ihre Produktionsimplementierung die externe Funktionalität umschließt.

public class SpreadsheetDocumentWrapper : ISpreadsheetDocument { 
    private SpreadsheetDocument excelDoc; 
    public SpreadsheetDocumentWrapper(SpreadsheetDocument excelDoc) { 
     this.excelDock = excelDock; 
    } 

    public Sheet GetSheet(string name) { 
     return excelDoc.WorkbookPart.Workbook.Descendants<Sheet>() 
      .SingleOrDefault(s => s.Name == sheetName); 
    } 

    public WorksheetPart GetPartById(string id) { 
     return (WorksheetPart)excelDoc.WorkbookPart.GetPartById(id); 
    } 
} 

Also, was Sie tun müssen, ist auf Ihrem ExcelDocument Klasse zu suchen, identifizieren seine Abhängigkeiten und abstrakt diese Abhängigkeiten heraus in Dienstleistungen, die Sie für Unit-Tests spotten kann.

+0

Danke Nkosi, gut beschrieben. Ich versuche jetzt zu verspotten. Ich habe das Beispiel hier erstellt: https://dotnetfiddle.net/KZSN5B. Könnten Sie bitte vorschlagen, wie das Gerät für GetWorksheetPart aussehen würde? –

+0

Hat dies als neue Frage veröffentlicht. Da ist dieser bereits beantwortet. Danke noch einmal. http://stackoverflow.com/questions/38638048/mocking-openxml-with-moq –