Il existe trois façons d'organiser des tests unitaires: Test par appareil, classe ou fonction. Mais l'attribut NUnit pour TestClass s'appelle TestFixture. Y a-t-il des raisons historiques à cela?Pourquoi testerFixture au lieu de TestClass?
La raison historique principale est que NUnit a commencé sa vie comme un port droit de JUnit et que junit l'a appelé banc de test.
NUnit 1.0 était avant mon temps mais on m'a dit qu'il a commencé par renommer tous les fichiers .java dans JUnit en fichiers .cs et en essayant de compiler. Il a été réparé à partir de là et une interface a été ajoutée. Quand j'ai rejoint sur NUnit 2.0 il y avait encore une méthode dans NUnit 1.0 appelée IsVisualAgeForJava depuis JUnit avait un comportement spécial pour cela à ce moment.
Dans NUnit 2.0, notre but était de rendre NUnit plus .NET. Nous avons donc ajouté les attributs et un tas d'autres choses. Nous venions tous d'horizons java et avions travaillé avec JUnit pendant des années. Il semblait assez naturel d'utiliser [TestFixture].
Maintenant que vous demandez à ce sujet, je viens de le chercher.
Un appareil de test est l'état de base fixe qui doit être établi avant l'exécution des tests, de sorte que les résultats soient prévisibles et reproductibles. Dans les frameworks de tests unitaires, nous utilisons les attributs/méthodes SetUp et TearDown pour créer/détruire le dispositif de test (par exemple, initialiser les variables d'instance avec les bons objets).
Je respecte la réponse de Mike Two, mais j'affirmerais que l'équipe de NUnit s'est trompée et que l'utilisation de [TestFixture] est une verrue sémantique sur le visage de NUnit. Une classe de test n'est pas une unité. D'après ce que j'ai pu comprendre à propos de JUnit, je n'ai trouvé aucune référence à une classe de test en tant qu'appareil de test, et je n'ai pas trouvé beaucoup de discussion sur les "appareils de test" faisant référence aux classes de test. Au contraire, toute la discussion JUnit/xUnit sur les appareils se rapporte à l'installation et au démontage, qui, bien sûr, sont les méthodes courantes utilisées pour configurer les appareils de test réels.
Notez que dans NUnit 2.5, vous pouvez supprimer l'annotation [TestFixture].
Mise à jour: (Juillet 2012)
Je viens juste de lire le Livre de concombre et à la page 99, l'auteur Matt Wynne explique l'origine de l'utilisation de "fixation". Je cite:
Il existe une longue tradition (provenant du monde matériel, où les appareils de test sont apparus) d'appeler un lien entre le système de test et le système testé. C'est le rôle de "code de collage" que nous avons appelé dans ce livre comme code d'automatisation. Le cadre de test FIT utilise ce sens du terme. Certains outils de test unitaire (tels que NUnit) ont encore compliqué le problème en faisant référence à la classe de cas de test elle-même en tant que fixture. Voilà pour une langue omniprésente! (Wynne & Hellesoy, 2012)
Je suis d'accord avec vous. C'était une erreur. Une fois qu'il est là, il est difficile de reprendre. Cependant, je pense qu'il y avait un comportement similaire dans JUnit à l'époque. Je pourrais avoir complètement tort. Tout était au début de 2002 et je pourrais me souvenir d'elle incorrectement. Dans tous les cas, vous avez raison d'affirmer qu'une classe de test et un appareil sont des choses différentes. –
Merci Mike Two, je suis toujours fasciné par les histoires étourdies derrière les projets dans notre métier. Je réalise aussi que si je ne l'aime pas, je ne devrais pas pleurnicher mais soumettre un patch. Je me demande si je suis trop pédant puisque personne d'autre n'a fait ce changement à NUnit à ce jour. – ybakos
J'ai envisagé de le changer plusieurs fois. Je heurte un mur de problèmes avec la rétrocompatibilité.J'ai arrêté le travail régulier de NUnit il y a des années donc je n'ai pas l'intention de le changer à l'avenir. –