Personnalisation de l'interface utilisateur graphique NUnit pour les tests pilotés par données

Question

Mon projet de test consiste en un ensemble de fichiers de données d'entrée qui est introduit dans un logiciel tiers hérité. Puisque les fichiers de données d'entrée pour ce logiciel sont difficiles à construire (pas quelque chose qui peut être fait intentionnellement), je ne vais pas ajouter de nouveaux fichiers de données d'entrée.

Chaque fichier de données d'entrée sera soumis à un ensemble de "fonctions de test". Certaines fonctions de test peuvent être appelées indépendamment. D'autres fonctions de test représentent les étapes d'une opération séquentielle - si une étape précédente échoue, les étapes suivantes n'ont pas besoin d'être exécutées.

J'ai expérimenté avec le cas de test paramétré NUnit (TestCaseAttribute et TestCaseSourceAttribute), en passant dans la liste des fichiers de données en tant que cas de test. Je suis généralement satisfait de la possibilité de sélectionner les données d'entrée pour les tests.

Cependant, je voudrais voir s'il est possible de personnaliser la structure arborescente de son interface graphique, de sorte que les "fonctions de test" deviennent les enfants des "données d'entrée". Par exemple:

• fichier # 1
  • CheckFileTypeTest
  • GetFileTopLevelStructureTest
  • CompleteProcessTest
    • StageOneTest
    • StageTwoTest
    • StageThreeTest
• fichier # 2
  • CheckFileTypeTest
  • GetFileTopLevelStructureTest
  • CompleteProcessTest
    • StageOneTest
    • StageTwoTest
    • StageThreeTest

Cela sera utile pour identifier l'étape qui a échoué lors du traitement d'un fichier d'entrée particulier.

Y a-t-il des trucs et astuces qui vont permettre la nouvelle disposition des arbres? Ai-je besoin de personnaliser NUnit pour obtenir cette mise en page?

Modifié: Voir la question Term for unit testing that separates test logic from test result data pour une introduction au concept de séparation des données de test et du code de test. Dans ma situation, la séparation est motivée par des préoccupations pratiques et non par des raisons idéologiques. Les sources de mes fichiers de données de test sont "dans la nature".

Autre utilisation anecdotique de tests pilotés par les données:

• http://www.clear-lines.com/blog/post/Data-driven-tests-with-NUnit-25.aspx
• http://www.clear-lines.com/blog/post/No-Tolerance-for-NUnit-Data-Driven-tests.aspx

Answer 1

Vous ne va probablement pas être en mesure de modéliser la structure exactement comme celui-ci. Les tests ne peuvent exister que dans TestFixtures (classes) et la seule chose qui vous permet d'imbriquer des niveaux arbitraires dans l'interface graphique sont des espaces de noms.

Ce que vous pouvez faire est la suivante:

* File001 (namespace) 
    * Tests_File001 (class, text fixture) 
    * CheckFileTypeTest (method, test) 
    * GetFileTopLevelStructureTest (method, test) 
    * CompleteProcessTest (namespace) 
    * TestsCompleteProcessTest (class, text fixture) 
     * StageOneTest (method, test) 
     * StageTwoTest (method, test) 
     * StageThreeTest (method, test) 

Je suppose que vous avez actuellement une configuration plus le long des lignes de

[Test] 
[TestCaseSource("TestFiles")] 
public void StageOneTest(String file) 
{ 
} 

où une méthode de test vérifie une chose spécifique et que vous exécutez ce test pour chaque fichier. Dans ce cas, vous devrez simplement supprimer les attributs et appeler cette méthode à partir de vos nouveaux tests. J'ai également l'impression que vous voulez que vos tests s'exécutent dans un ordre spécifique et que les différents testeurs exécutent votre test dans différents ordres. Je ne suis au courant d'aucun moyen de le faire et, en règle générale, vous ne devriez pas. Aucun test ne devrait dépendre d'un autre test ayant réussi. En supposant que vos tests prennent un peu de temps et que vous ne voulez pas exécuter tous les tests "ultérieurs" si un test "antérieur" a déjà échoué, vous pouvez les placer dans des catégories appropriées comme: "Preliminary", "Stage1 ", etc. Ensuite, vous pouvez exécuter une catégorie après l'autre et voir où le premier échoue.

J'espère que cela vous aide.