Side-by-side fonctionnelle et tests d'acceptation (SpecFlow)

Question

Edit: Cette question semble être related

Cette question ne concerne pas les différences entre les tests fonctionnels et de réception! Presque toutes les informations que j'ai pu trouver sur le web expliquent juste la différence entre elles. Je sais que les tests fonctionnels (FT) traitent des conditions marginales et des scénarios de bogues, tandis que les tests d'acceptation (AT) répondent aux exigences métier. Je réalise les deux avec SpecFlow. J'ai quelques difficultés à envelopper la tête autour de la séparation des deux, d'une perspective de structure de projet/hiérarchie. Actuellement, j'ai un projet de test unitaire avec un dossier AcceptanceTests et un dossier FunctionalTests. Toutes mes définitions d'étapes sont regroupées dans un dossier StepDefinitions.

Je trouve que je dois beaucoup me répéter et que le volet MsTest ne fait que tout mélanger lorsque je groupe sur Traits. Je veux établir ce que la norme de l'industrie est là-bas, donc j'ai cinq questions:

• -ce que je répète l'histoire "In order to... as a... I want to..." dans une fonction de fichier séparé pour AT et de FT de? Est-ce que je répète tous les scénarios d'AT dans les FT, ou seulement les scénarios de conditions marginales?

• Devrais-je conserver les AT et les FT dans leurs propres espaces de noms et/ou leurs propres projets? Dois-je essayer d'appeler les méthodes du scénario du FT à partir des définitions des étapes de l'AT, vu que le travail de grognement est de toute façon effectué par les FT?

• Tout conseil concernant ma configuration actuelle (par exemple, est-ce trop compliqué de faire les deux?) Est le bienvenu.

Answer 1

Il est trop compliqué de faire les deux en tant que caractéristiques SpecFlow.

Les tests d'acceptation sont très utiles, mais ils demandent beaucoup de travail d'écriture, de maintenance et de longue durée. Vous devez donc en avoir le moins possible tout en continuant de capturer tous vos cas d'utilisation importants. Au lieu de cela, testez vos «conditions marginales et les scénarios de bogues» avec un outil de test unitaire tel que NUnit.

Vous pouvez trouver que pour une fonctionnalité donnée, vous voulez un scénario unique dans lequel l'utilisateur fait une erreur afin que vous spécifiez comment votre traitement des erreurs fonctionne. Mais vous ne voulez certainement pas un scénario pour chaque erreur spécifique; Au lieu de cela, capturer ceux dans les tests unitaires de votre code de validation.