2011-10-02 6 views
2

ContexteNUnit vs Manuel des tests unitaires

J'ai récemment essayé de développer une série de tests pour les tests de régression d'une application particulière. J'ai utilisé NUnit et n'ai eu aucun problème.

J'ai rencontré le problème de l'envoi de paramètres aux tests NUnit, pour lesquels aucune réponse satisfaisante ne semble exister.

Question

Dites je mets en œuvre d'un simple appareil de contrôle de l'unité qui charge une classe, exécute le démarrage, test et méthodes de démontage dans l'ordre, la capture d'exceptions et puis décharge l'assemblée. Quels sont les inconvénients de faire cela par rapport à l'utilisation de NUnit?

Dans ce scénario, je peux facilement passer des paramètres à mes cas de test, ou faire n'importe quelle autre chose folle que je pourrais trouver. Mais ce qui m'inquiète, c'est ce que je perds en abandonnant NUnit.

+2

pourquoi avez-vous besoin de passer des paramètres à un test unitaire? On dirait que vous testez plus d'une unité ... –

+0

Les tests sont exécutés à distance et nécessitent des informations sur qui les a exécutés à des fins de consignation. Une question valable mais malheureusement pas ce que je demande ici. – prestomanifesto

+2

@nathangonzalez Selon ce que vous testez, il est possible d'être dans une situation où vous souhaitez exécuter le même test plusieurs fois avec des données légèrement différentes. Les tests paramétrés facilitent la tâche sans dupliquer plusieurs fois le même test. –

Répondre

6

Que perdez-vous? Ton temps.

Si vous travaillez pour un client ou une entreprise, ils vous paient (vraisemblablement) pour résoudre des problèmes commerciaux, et non pour écrire du code d'infrastructure. Certaines infrastructures peuvent être nécessaires pour répondre aux besoins de l'entreprise. Dans ce cas, c'est clairement pas. Vous réinventez la roue. Ne pas tomber dans le piège non inventé ici. Utilisez NUnit. Il prend en charge parameterized tests. Si NUnit ne répond pas à vos besoins, recherchez MbUnit or xUnit.net. Ou regardez SpecFlow, etc. pour le style BDD. Ou FitNesse pour les essais d'acceptation. Et ce n'est qu'une liste partielle!

Si vous écrivez un cadre de test par vous-même à des fins d'apprentissage, très bien! Sinon, vous perdez votre temps et/ou l'argent de votre entreprise.

Répondre aux aspects techniques

JUnit a été créé lors d'une long airplane trip. À l'époque, il n'y avait pas beaucoup d'alternatives. Rédaction d'un cadre de test n'est pas un énorme projet. L'écriture d'un disque robuste, complet et facile à utiliser est plus difficile. L'écriture de curseurs de test, l'intégration d'IDE, l'intégration de CI, l'intégration de couverture de code, etc. est beaucoup plus difficile. Et cela a été fait. Sauf si vous êtes Ayende Rahien, ne le faites pas!

En plus de l'intégration, vous perdez également features of NUnit que vous n'implémentez pas (et il y en a beaucoup). Je n'utilise pas tout cela, mais je compte sur beaucoup d'entre eux.

(Motion proposée de mes commentaires)

+0

Réponse très intéressante du point de vue de la productivité, même si je suis toujours intéressé par l'aspect technique de la question. – prestomanifesto

+0

Qu'entendez-vous par "aspect technique de la question"? Cette réponse n'est-elle pas staisfactory? –

Questions connexes