11
votes

Qu'est-ce qu'une bonne approche pour se débarrasser de la dépendance sur un streamerrisseur / filtream pour des tests unitaires?

Voici le scénario:

J'ai une méthode qui se lit dans un fichier via un fichier filtre et un streamreader dans .NET. Je voudrais appuyer sur cette méthode et en quelque sorte supprimer la dépendance sur l'objet StreamReader.

Idéalement, j'aimerais pouvoir fournir ma propre chaîne de données de test au lieu d'utiliser un fichier réel. À l'heure actuelle, la méthode utilise la méthode StreamReader.Readline. Quelle est une approche pour modifier la conception que j'ai maintenant pour que ce test soit possible?


0 commentaires

4 Réponses :


11
votes

dépend de flux et textreader à la place. Ensuite, vos tests d'unités peuvent utiliser MemoryStream et stringreader . (Ou charger des ressources de l'intérieur de votre appareil de test si nécessaire.)

Notez comment readline est initialement déclaré par textreader , pas streamreader .


2 commentaires

Mais cela ne voudrait-il que suspendre le problème? Toute classe qui utilise la "classe de lecteur" aurait alors besoin de créer le streamreader ou textreader ou dois-je manquer quelque chose?


@Royalts: ils pourraient utiliser n'importe quel textreader et flux implémentation. Dans tests, il pourrait s'agir d'un stringreader ; Dans le code réel, il pourrait s'agir d'un streamreader d'envelopper un fichier ou d'un flux de réseau, etc. (il n'est pas clair de la question de savoir si l'OP ait vraiment besoin d'un flux et a textreader ou juste un textreader .) Mais le point est celui en déplaçant la couche d'abstraction, vous obtenez plus de flexibilité.



3
votes

La solution la plus simple serait d'accepter la méthode d'accepter un flux en tant que paramètre au lieu d'ouvrir son propre filtream. Votre code actuel pourrait passer dans la FileStream comme d'habitude, tandis que votre méthode de test pourrait utiliser une filtrage différente pour les données de test, ou une mémoire de mémoire Morthstream remplie avec ce que vous vouliez tester (cela ne nécessiterait pas de fichier).


0 commentaires

2
votes

Sur le dessus de ma tête, je dirais que c'est une excellente occasion d'enquêter sur les mérites de Injection de dépendance .

Vous voudrez peut-être envisager de repenser votre méthode de manière à ce qu'il faut un délégué qui renvoie le contenu du fichier. Un délégué (la production One) peut utiliser les classes dans le système.IO, tandis que la seconde (pour tester unitaire), renvoie le contenu directement sous forme de chaîne.


0 commentaires

0
votes

Je pense que l'idée est de dépend de la dépendance à l'injection du textreader et de les moquer pour les tests unitaires. Je pense que vous ne pouvez que se moquer de la textreader car c'est une classe abstraite.

public class UnitTest1
{
    [Test]
    public void Test_Extract_First_Row_Mocked()
    {            
        //Arrange
        List<TradeInfo> listExpected = new List<TradeInfo>();
        var tradeInfo = new TradeInfo() { TradeId = "0453", FutureValue = 2000000, PresentValue = 3000000, NotionalValue = 400000 };
        listExpected.Add(tradeInfo);
        var textReader = MockRepository.GenerateMock<TextReader>();
        textReader.Expect(tr => tr.ReadLine()).Return("0453, 2000000, 3000000, 400000");
        var fileParser = new FileParser(textReader);
        var list = fileParser.ProcessFile();           
        listExpected.ShouldAllBeEquivalentTo(list);         

    }
}


0 commentaires