web-dev-qa-db-fra.com

Comment tester un lecteur de fichier?

Je travaille sur un projet avec quelques formats de fichiers. Certains formats sont spécifiés par .xsds, d'autres par la documentation sur leurs sites Web respectifs, et certains sont des formats internes personnalisés qui n'ont pas de documentation. Mwahahahaha.

Quel est le problème?

Je voudrais tester mes lecteurs de fichiers, mais je ne suis pas tout à fait sûr comment y aller. Le flux de l'application est en tant que tel:

file.___  ===> read by FileReader.Java ===> which creates a Model object

où l'interface FileReader est

public interface FileReader {
    public Model read(String filename);
}

Le Model a un certain nombre d'attributs peuplés lorsque le fichier est lu. Ça ressemble quelque chose comme

public class Model {
    List<String> as;
    List<String> bs;
    boolean isAPain = true;
    // ...
}

qu'avez-je essayé?

Ma seule idée était de créer des "générateurs" de fichier pour chaque format de fichier. Ces générateurs sont fondamentalement des constructeurs qui prennent quelques variables (par exemple, nombre de commentaires à générer dans un fichier) et génèrent un exemple de fichier que je lis puis lisez et comparez le Model avec les variables que j'ai utilisées pour générer initialement le fichier.

Cela a quelques problèmes, cependant:

  • Les fichiers qu'il génère ne sont pas look comme des fichiers réels. Le générateur n'est en aucun cas conscient du contexte.
  • Il est difficile de reconnaître si le générateur a généré pour des cas de bord depuis que je suis celui qui définit manuellement les variables. Cette méthode est à peine meilleure que moi créant une douzaine d'échantillons de fichiers.

Y a-t-il de meilleurs moyens de faire cela?

Modifier: Unité modifiée à l'intégration depuis que c'est ce que je veux dire.

EDIT2: Voici un exemple des cas de bord que j'ai mentionnés.

Chaque fichier représente un graphique composé de sommets et de bords. Ces sommets et bords peuvent être attachés de différentes manières, donc:

v1 -- e1 --> v2 <-- e2 -- v3

est différent de

v1 -- e1 --> v2 -- e2 --> v3

en ce que la direction des bords compte. Je ne sais pas si cela fait partie de la question, mais il est difficile de penser à tous les cas de bord pertinents lorsque je définirai manuellement le nombre de sommets, le nombre de bords et générer des connexions au hasard.

unit-testinglanguage-agnosticintegration-testsfile-handling
19
sdasdadas

Tout d'abord, parle de ce que sont vos objectifs:

  • vous ne voulez évidemment pas tester les "formats de fichiers" - vous souhaitez tester vos différentes implémentations FileReader

  • vous voulez trouver autant de types d'erreurs que possible par les tests automatiques

Pour atteindre cet objectif intégralement, je dois combiner différentes stratégies:

  • premièrement, les tests d'unités réelles: vos implémentations FileReader seront composées de nombreuses pièces et fonctions différentes. Écrire de petits tests qui testent chacun d'eux isolément; Concevez vos fonctions d'une manière dont ils n'ont pas vraiment besoin de lire les données d'un fichier. Ce type de test vous aidera à tester la plupart de vos cas de bord.
  • deuxièmement, les fichiers générés: ce sont ce que j'appellerais des tests d'intégration. Ces fichiers vous aideront à suivre les défaillances différent du point 1, par exemple, des combinaisons de paramètres spécifiques, des erreurs d'accès au fichier, etc. Pour créer de bons cas de test, il sera également utile de connaître certaines techniques classiques telles que le regroupement de cas de test dans classes d'équivalence ou test de la valeur limite. Obtenez une copie de Ce livre de Glenford Myers pour en savoir plus à ce sujet. L'article Wikipedia sur sur les tests logiciels est une bonne ressource également.
  • troisièmement, essayez d'obtenir des données du monde réel: il peut être difficile de vérifier que ces fichiers sont évalués correctement par votre FileReaders, mais cela vaut la peine de le faire car il trouve souvent des bugs non révélés par le premier. Deux stratégies. Certaines personnes appelleraient ces éléments types aussi "tests d'intégration", d'autres préfèrent "tests d'acceptation", mais en fait, le terme n'a pas d'importance.

IMHO Il n'existe pas d'approche "à court terme" qui vous apporterait l'avantage des trois stratégies "pour le prix d'un". Si vous souhaitez détecter des cas d'avance ainsi que des échecs dans des cas standard ainsi que des cas réels, vous devez investir au moins certains - plus probablement beaucoup - effort. Heureusement, toutes ces approches peuvent être utilisées pour créer des tests automatiques et reproductibles.

Au-delà de cela, vous devez vous assurer que votre FileReaders ne masque aucune erreur lorsque vous lisez ces données - créez des chèques/affirmations intégrées, lancez des exceptions lorsque quelque chose ne va pas en interne, etc. Cela donne beaucoup à votre code de test Une meilleure chance de détecter des erreurs, même lorsque vous n'avez pas de fichier de test explicite ou de test de test pour une situation inattendue.

19
Doc Brown