Tests definition by Martin Fowler

Dans une série d’articles récents (références ici), Martin Fowler fait un focus sur différentes sortes de tests (en-dehors des test unitaires). Voici un petit résumé de ce que j’en ai tiré :

Martin Fowler se base sur la pyramide de test explicitée par Mike Cohn dans Succeding with Agile.

Testpyramid

A laquelle il rattache l’ensemble des tests suivants :

BroadStackTest : test qui utilise une grande partie des fonctionnalités de l’application. On parlera aussi de test end-to-end. Ce genre de test se réalise donc régulièrement en manipulant l’UI.

Pas de bouchons, pas de mock, on teste l’application dans sa version finale avec les liens vers tous les composants. Ce sont cependant des tests assez longs à exécuter comparativement aux ComponentTests.

BusinessFacingTest : définit comme un test permettant d’utiliser un langage commun (Domain Specific Language) entre le spécifieur et l’équipe de réalisation de la fonctionnalité. On peut l’automatiser via des outils comme Cucumber. Pour moi, ça s’apparente à du BDD. Ils peuvent être implémentés sous la forme de BroadStackTest étant donné qu’ils sont orientés utilisateur ou de ComponentTest ce qui leur vaudra d’être plus facilement maintenables et plus rapidement exécutés.

UserJourneyTest : test permettant de décrire un ou des scénarios d’utilisation de l’application. C’est une forme de BusinessFacingTest permettant de définir une suite d’interactions que l’utilisateur-type fera en utilisant les diverses fonctionnalités de l’application. Ce type de test est en général implémenté comme un BroadStackTest. En comparaison au StoryTests, ce type de tests n’est pas lié spécifiquement à une User Story. Ainsi, si une story change de comportement, il suffira de mettre à jour une partie du UserJourneyTest, et rarement l’intégralité du test (ou de créer un nouveau test).

SubcutaneousTest : test se trouvant juste en-dessous de l’UI permettant de « taper » sur les fonctionnalités de l’application sans utiliser l’UI. Ce qui peut être plus rapide. Le warning sur ce genre de test est que selon la technologie utilisée, si une majeure partie du comportement de l’application est défini dans l’UI et non dans le code côté « service », ce comportement ne sera pas testé. Peut être assimilé à un BroadStackTest.

ComponentTest : test se limitant à une sous-partie du système. Il diverge du BroadStackTest qui lui s’étend plus sur l’ensemble de l’application. Ils sont donc plus simples à implémenter et s’exécutent plus facilement. Ils permettent donc d’isoler un sous-système et de vérifier son comportement, toutefois sans se soucier de ses interactions avec d’autres éléments.

StoryTest : ce sont des BusinessFacingTests utilisés pour valider le comportement d’une User Story. On les assimile donc à des tests d’acceptation définis par le spécifieur et l’équipe au moment de la définition de la story. Ce sont généralement des BroadStackTest. Cependant, ce genre de test peut causer certains soucis, amener à de la duplication de comportement au sein des tests (fonctionnalités qui se recoupent, etc…) ce qui induit des difficultés de maintenabilité des tests. Il ont de plus un long temps d’exécution ce qui induit une violation de la pyramide de test pour bon nombre d’entre eux. Il est donc privilégié d’utiliser des UserJourneyTests associés à des ComponentTests.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s