La manière Agile: test D'intégration vs test fonctionnel ou les deux? [fermé]
je travaille dans un bureau qui est Agile depuis un certain temps maintenant. Nous utilisons Scrum pour la gestion de projets et mixons les pratiques d'ingénierie de XP. Cela fonctionne bien et nous en tirons constamment des leçons et nous affinons notre processus.
j'aimerais vous parler de nos pratiques habituelles pour les tests et obtenir des commentaires sur la façon dont cela pourrait être amélioré:
TDD: première ligne de défense Nous sommes assez religieux sur les tests d'unité et je dirais que nos développeurs sont aussi assez expérimentés pour écrire des tests complets et isoler toujours le SUT avec des moqueries.
Essais D'Intégration
Pour notre usage, les tests d'intégration sont essentiellement les mêmes que les tests unitaires sans utiliser les mocks. Cela tend à saisir quelques problèmes qui ont glissé à travers les tests unitaires. Ces tests ont tendance à être difficiles à lire car ils impliquent généralement beaucoup de travail dans les sections before_each et after_each . le système doit souvent atteindre un certain état pour que les tests soient significatifs.
Test Fonctionnel Nous le faisons habituellement de façon structurée, mais manuelle. Nous avons joué avec le sélénium et le moulin à vent, qui sont cool, mais pour nous au moins pas encore tout à fait là.
j'aimerais savoir comment quelqu'un d'autre fait les choses. Pensez-vous que si des Tests D'intégration ou des tests fonctionnels sont effectués bien assez de l'autre peut être ignoré?
10 réponses
Unité, intégration et tests fonctionnels, bien qu'exerçant le même code, l'attaquent de différentes perspectives. Ce sont ces points de vue qui font la différence, si vous deviez laisser tomber un type de test alors quelque chose pourrait faire son chemin dans cet angle.
de plus, les tests unitaires ne sont pas vraiment une question de tester votre code, surtout si vous pratiquez le TDD. Le processus de TDD vous aide à concevoir votre code mieux , vous venez d'obtenir 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 continu. Je recommande fortement d'en installer un ( Hudson est facile à installer). Ensuite, vous pouvez faire exécuter vos tests d'intégration et de fonctionnement à chaque contrôle du code.
nous avons expérimenté qu'un ensemble solide de tests de sélénium résume en fait ce que le client attend de la qualité vraiment bien. Donc, essentiellement, nous avons eu cette discussion: si écrire des tests de sélénium était aussi facile que d'écrire des tests unitaires, nous devrions nous concentrer moins sur les tests unitaires.
Et est un bug quelque part qui n'a aucune conséquence dans l'application, qui se soucie vraiment? Mais il y a toujours les problèmes autour de la vraie vie complexités; êtes-vous sûr que vos tests fonctionnels saisissent les bons 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é, en écrivant des tests sélénium (en utilisant un langage de programmation APPROPRIÉ, pas sélénois) does get really simple and fun once you drill through the initial problems. Mais nous ne sommes pas prêts à renoncer à nos tests....
je dirais (et ce n'est qu'une question d'opinion) que vos tests fonctionnels sont vos tests vrai . 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.
on dirait que vous avez un bon système. Garder tout si vous n'avez rien à perdre.
chez mon client actuel, nous ne faisons pas vraiment de distinction entre les tests unitaires et les tests d'intégration. Les entités commerciales dépendent tellement de la couche de données sous-jacente (à l'aide d'un cadre ORM propre) qu'en fait nous avons peu ou pas de véritables tests unitaires.
le serveur de compilation est configuré avec intégration continue (CI) dans Team Build et pour éviter que cela ne s'embourbe trop avec des tests lents (la suite de test complète prend plus d'une heure à tourner sur le serveur) nous avons séparé les des tests " lents "qui se déroulent deux fois par jour et des tests" rapides " qui se déroulent dans le cadre d'une intégration continue. En définissant un attribut sur la méthode de test, le serveur de compilation peut faire la différence entre les deux.
en général, les tests" lents " sont ceux qui nécessitent l'accès aux données, l'utilisation de services web ou autres. Ceux-ci seraient considérés comme des tests d'intégration ou des tests fonctionnels par convention commune. Exemples: CRUD-tests, business validation rule tests qui ont besoin d'un ensemble de objets avec lesquels travailler, 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 considère que tout test qui s'exécutent en dixièmes de seconde ou moins "rapide". Tout le reste est lent et ne devrait probablement pas être géré en tant que partie de CI.
je suis d'accord que vous ne devriez pas trop se raccrocher à la "saveur" du test que vous utilisez dans le cadre du développement (expression critères d'acceptation en tant que tests est l'exception bien sûr). Le développeur individuel devrait utiliser son jugement pour décider quel type de tests convient le mieux à son code. Insister sur les tests unitaires pour une entité commerciale pourrait ne pas révéler les défauts d'un test de crudité et ainsi de suite...
j'assimile les tests unitaires au fait de s'assurer que les mots d'un paragraphe sont épelés correctement. Un test fonctionnel, c'est comme s'assurer que le paragraphe a du sens, et qu'il circule bien à l'intérieur du document dans lequel il vit.
j'ai tendance à ne pas séparer les différentes saveurs de test en TDD. Pour me TDD est le développement basé sur les tests, pas le développement basé sur les tests unitaires. Ainsi, ma pratique de TDD combine des tests unitaires, des tests d'intégration, des tests de fonctionnement et d'acceptation. Il en résulte que certains composants sont couverts par certains types d'essais et que d'autres sont couverts par d'autres types d'essais d'une manière très pragmatique.
j'ai posé une question sur la pertinence de cette pratique et la réponse courte était qu'en pratique la séparation est entre des tests rapides/simples qui s'exécutent automatiquement à chaque Construction et des tests lents/complexes qui s'exécutent moins souvent.
Mon entreprise a fait des tests fonctionnels, mais pas d'unité ou de tests d'intégration. J'essaie d'encourager nous les adoptons, je les vois comme encourageant une meilleure conception et une indication plus rapide que tout va bien. Avez-vous besoin de tests unitaires si vous n'tests fonctionnels?
j'aime vraiment le concept de Gojko Adzic d'un "face saving test" comme un moyen de déterminer ce que vous testez via L'UI: http://gojko.net/2007/09/25/effective-user-interface-testing/
vous devez tous les faire parce que l'unité,l'intégration et les tests fonctionnels servent tous à des fins différentes.
Appartient à moi un point important est que la façon écriture test est très important et TDD n'est pas enought, BDD (behavior driven development) donner une bonne approche...