La manière agile: tests d'intégration vs tests fonctionnels ou les deux?

Question

Je travaille dans un bureau qui a été fait Agile pour un certain temps maintenant. Nous Scrum pour la gestion de projet et de mélange dans les pratiques d'ingénierie de XP. Il fonctionne bien et nous sommes constamment à l'apprentissage des leçons et d'améliorer nos processus.

Je tiens à vous informer de nos pratiques habituelles pour les tests et obtenir de la rétroaction sur la façon dont cela pourrait être amélioré:

TDD: Première Ligne de Défense Nous sommes très religieux sur les tests unitaires et je dirais que nos développeurs sont également assez d'expérience pour écrire des tests exhaustifs et toujours isoler le SUT avec des simulacres.

Les Tests D'Intégration Pour notre usage, les tests d'intégration sont fondamentalement les mêmes que les tests unitaires juste sans l'aide de la simulacres. Cela a tendance à attraper quelques-unes des questions qui sont passés à travers les tests unitaires. Ces tests ont tendance à être difficile à lire, car ils impliquent généralement beaucoup de travail ou dans l' before_each et after_each sections de la spécification du cadre du système a souvent à atteindre un certain état pour que les tests soient significatifs.

Les Tests Fonctionnels Nous avons l'habitude de le faire d'une manière structurée, mais manuel de la mode. Nous avons joué avec le Sélénium et le Moulin à vent, qui sont cool, mais pour nous, au moins pas tout à fait encore là.

J'aimerais savoir comment quelqu'un d'autre est en train de faire des choses. Pensez-vous que si les Tests d'Intégration ou de Tests Fonctionnels sont en train d'être fait assez bien l'autre peut être ignoré?

Answer 1

Unitaires, d'intégration et de test fonctionnel, bien que l'exercice du même code, sont en train de l'attaquer à partir de perspectives différentes. Ce sont ces perspectives qui font la différence, si vous déposez un type de test alors quelque chose qui pourrait fonctionner son chemin dans de l'angle.

Aussi, les tests unitaires n'est pas vraiment à propos de tester votre code, surtout si vous êtes pratiquer le TDD. Le processus de TDD vous aide à concevoir votre code mieux, vous obtenez juste le bonus supplémentaire d'une suite de tests à la fin de celui-ci.

Vous n'avez pas mentionné si vous avez un serveur d'intégration continue en cours d'exécution. Je vous recommande fortement d'en organiser un (Hudson est facile à mettre en place). Ensuite, vous pouvez avoir votre intégration et tests fonctionnels exécuter à l'encontre de tous les vérifier dans le code.

Answer 2

Nous avons connu un solide ensemble de sélénium tests en réalité résume ce que le client attend de qualité vraiment bien. Donc, en substance, nous avons eu cette discussion: Si l'écriture de sélénium tests était aussi facile que d'écrire des tests unitaires nous devrions nous concentrer moins sur les tests unitaires.

Et si il y est un bug quelque part qui n'a aucune conséquence dans l'application, qui se soucie vraiment? Mais il y a toujours les questions entourant la vie réelle complexité; êtes-vous sûr que vos tests fonctionnels sont en train de capturer le bon scénarios ? Il peut y avoir des complexités sous-jacentes causés par d'autres systèmes qui ne sont pas directement visibles dans le comportement de l'application.

En réalité, l'écriture de sélénium tests (à l'aide d'un bon langage de programmation, pas selenese) n'est vraiment simple et amusant une fois que vous percez à travers la problématique initiale. Mais nous ne sommes pas disposés à abandonner nos tests unitaires encore tout à fait....

Answer 3

Les tests unitaires, les tests d'intégration et les tests fonctionnels ont tous des objectifs différents. Vous ne devez pas en éliminer un simplement parce que les autres fonctionnent à un niveau de fiabilité élevé.

Answer 4

Je dirais (et ceci n’est qu’une question d’opinion) que vos tests fonctionnels sont vos vrais tests. C'est-à-dire ces tests qui simulent réellement l'utilisation réelle de votre application. Pour cette raison, ne vous en débarrassez jamais, quoi qu'il arrive.

Il semble que vous ayez un système décent. Gardez tout si vous n'avez rien à perdre.

Answer 5

À mon client actuel nous n'avons pas vraiment séparés entre l'unité-tests et intégration-tests. Les entités commerciales sont tellement dépendants sur les données sous-jacentes de la couche (à l'aide d'un homegrown ORM) qui, en effet, nous avons peu ou pas de véritable unité-tests.

Le serveur de build est mis en place avec l'intégration continue (CI) dans l'Équipe de la construction et pour éviter que cela s'enlise trop lent tests (le test complet de la suite prend plus d'une heure pour s'exécuter sur le serveur), nous avons séparé les tests sur la "lenteur" des tests qui est exécuté deux fois par jour et "rapide" des tests qui se exécutent dans le cadre de l'intégration continue. En définissant un attribut sur le test de la méthode de l'accumulation serveur peut faire la différence entre les deux.

En général, la "lenteur" des tests sont tout qui doit faire de l'accès aux données, l'utilisation de services web ou similaire. Celles-ci seraient considérées comme des tests d'intégration ou de tests fonctionnels par convention commune. Des exemples sont: CRUD-tests, les affaires de la règle de validation des tests qui ont besoin d'un ensemble d'objets de travail, etc.

"Rapide" des tests sont plus comme unité de tests, où il est raisonnablement possible d'isoler un objet unique de l'état et le comportement pour le test.

Je le considère comme un test qui s'exécutent en dixièmes de seconde ou moins "rapide". Tout le reste est lent et ne devrait probablement pas être exécuté dans le cadre de l'IC.

Je suis d'accord que vous ne devriez pas avoir trop accroché sur la "saveur" de test que vous utilisez dans le cadre de développement (exprimant les critères d'acceptation que les tests est l'exception, bien sûr). Le développeur doit utiliser leur jugement pour décider de ce type de tests les mieux adaptées à leur code. En insistant sur l'unité-tests pour une entreprise pourrait ne pas révéler les défauts d'un CRUD-test et ainsi de suite...