2010-10-11 9 views
6

J'ai commencé à utiliser une approche TDD pour développer une petite application qui lit des données à partir de fichiers Excel. En utilisant une approche de type de modèle de dépôt, je suis arrivé à un obstacle qui me déconcerte.Utilisation de TDD avec OpenXml-SDK

Afin de lire les fichiers Excel, j'utilise OpenXml-SDK. Maintenant, la lecture d'un fichier Excel à l'aide du SDK nécessite généralement plusieurs étapes sinon plus pour obtenir les valeurs que vous voulez lire.

L'approche que j'ai prise jusqu'ici est reflétée dans la fonction de test et d'accompagnement suivante.

[Test] 
    public void GetRateData_ShouldReturn_SpreadSheetDocument() 
    { 
     //Arrange 
     var fpBuilder = new Mock<IDirectoryBuilder>(); 
     fpBuilder.Setup(fp => fp.FullPath()).Returns(It.IsAny<string>()); 

     var doc = new Mock<IOpenXmlUtilities>(); 
     doc.Setup(d => d.OpenReadOnlySpreadSheet(It.IsAny<string>())) 
      .Returns(Mock.Of<SpreadsheetDocument>()); 

     swapData = new SwapRatesRepository(fpBuilder.Object, doc.Object); 

     //Act 
     var result = swapData.GetRateData(); 

     //Assert 
     doc.Verify(); 
     fpBuilder.Verify(); 
    } 

public class SwapRatesRepository: IRatesRepository<SwapRates> 
{ 
    private const string SWAP_DATA_FILENAME = "DATE_MKT_ZAR_SWAPFRA1.xlsx"; 
    private IDirectoryBuilder builder; 
    private IOpenXmlUtilities openUtils; 

    public SwapRatesRepository(IDirectoryBuilder builder) 
    { 
     // TODO: Complete member initialization 
     this.builder = builder; 
    } 

    public SwapRatesRepository(IDirectoryBuilder builder, 
             IOpenXmlUtilities openUtils) 
    { 
     // TODO: Complete member initialization 
     this.builder = builder; 
     this.openUtils = openUtils; 
    } 

    public SwapRates GetRateData() 
    { 
     // determine the path of the file based on the date 
     builder.FileName = SWAP_DATA_FILENAME; 
     var path = builder.FullPath(); 

     // open the excel file 
     using(SpreadsheetDocument doc = openUtils.OpenReadOnlySpreadSheet(path)) 
     { 
      //WorkbookPart wkBookPart = doc.WorkbookPart; 
      //WorksheetPart wkSheetPart = wkBookPart.WorksheetParts.First(); 
      //SheetData sheetData = wkSheetPart.Worksheet 
      //         .GetFirstChild<SheetData>(); 

     } 

     return new SwapRates(); // ignore this class for now, design later 
    } 
} 

Cependant, les prochaines étapes après la feuille de calcul est ouverte serait réellement commencer à interroger le modèle d'objet Excel pour récupérer les valeurs. Comme noté ci-dessus, je me sers de mocks pour tout ce qui est ouvert xml. Cependant, dans certains cas, les objets ne peuvent pas être moqués (ou je ne sais pas comment les railler puisqu'ils sont statiques). Cela a donné lieu à IOpenXmlUtilities qui sont simplement de simples appels wrapper dans le OpenXml-SDK. En termes de conception, nous savons que la lecture de données à partir de fichiers Excel est une solution à court terme (6-8 mois), ces tests ne concernent donc que l'accès au référentiel/données pour le moment. De toute évidence, je ne veux pas quitter l'approche TDD (aussi tentante que cela puisse être), alors je suis à la recherche de conseils et de conseils sur la façon de poursuivre mes efforts TDD avec le SDK OpenXml. L'autre aspect concerne la moquerie - je suis confus quant à quand et comment utiliser des simulacres dans ce cas. Je ne veux pas écrire sans le savoir des tests qui testent le OpenXml-SDK.

* Note de côté: Je sais que la SOLIDITÉ de mon design peut être améliorée mais je laisse cela pour l'instant. J'ai un ensemble de tests séparés qui se rapportent à l'objet builder. L'autre effet secondaire qui peut se produire est la conception d'une bibliothèque wrapper OpenXML-SDK. Edit: À l'époque, en créant les wrappers OpenXML-SDK pour OpenXML-SDK, j'ai utilisé un motif de conception similaire (ou exact) appelé Adaptor pattern.

+0

Vous ne savez pas si cela vous sera utile, mais ici: http://stackoverflow.com/questions/3356503/automated-testing-openxml-sdk –

Répondre

3

Si vous ne pouvez pas vous moquer de lui et ne pouvez pas créer un petit unittest, il pourrait être préférable de le prendre à un niveau supérieur et de faire un test de scénario. Vous pouvez utiliser les méthodes [TestInitialize] et [TestCleanup] pour créer une configuration pour le test.

en utilisant Pex and Moles pourrait être une autre façon de le tester.