Au moment d'écrire cette réponse, j'ai réalisé qu'il ne s'agissait pas de tests, mais de documentation. Vous devez d'abord lire le manifeste agile :
[Nous apprécions] un logiciel fonctionnel plutôt qu'une documentation complète
Vous devez donc rendre vos spécifications exécutables, c'est-à-dire les écrire sous la forme d'un ensemble de tests entièrement automatisé.
La rédaction de spécifications basées sur des histoires est-elle une bonne idée?
Oui, à mon humble avis, ça l'est. C'est ce qu'on appelle le «développement axé sur le comportement» ou la «spécification par l'exemple». En rubis, il y a un excellent outil de concombre qui aide beaucoup.
Le problème est que, parce qu'il y a tellement d'histoires, ce n'est pas immédiatement clair, pour aucune partie du système, quelles histoires s'y rapportent.
Pourquoi voulez-vous que ce soit clair? Je veux dire, avez-vous vraiment besoin d'une matrice de traçabilité "test / code"? L'avantage d'écrire des tests en tant que spécification est que vous n'avez pas besoin d'une traçabilité séparée «exigences / tests», car les tests deviennent des exigences. Aux fins des tests d'intégration, vous devez traiter votre logiciel dans son ensemble, et non comme des parties distinctes.
Vous pourriez avoir besoin d'un outil de couverture pour voir s'il y a des modules "morts", des parties de votre système non couvertes par vos tests de spécifications. Mais vous ne devriez vraiment pas vous soucier de la spécification à laquelle ce code particulier correspond. Cela devrait être vice versa: à partir d'une spécification particulière, vous devez savoir quelle partie du système lui correspond. Vous ne devez pas vous inquiéter de la duplication de vos spécifications. Et si vous appliquez un principe DRY à votre code, il y aurait des dizaines de spécifications exécutant le même code.
Cela fonctionne au moment des développeurs, à chaque sprint, les développeurs reçoivent simplement une spécification décrivant ce qu'ils doivent faire et les changements qu'ils doivent apporter. Mais en termes de maintenance de cette liste d'histoires et de tests, cela commence à avoir des bogues de suivi très difficiles et en général juste à maintenir les spécifications, car une fonctionnalité de l'écran peut avoir été documentée à un certain nombre d'endroits différents car elle est divisé par histoire.
Il n'est pas rare que des centaines de tests d'intégration soient interrompus par un petit changement dans un module critique. C'est là que les tests unitaires entrent en jeu.
Vous devez structurer vos tests en tant que tels afin de pouvoir déterminer si un test particulier couvre une exigence de haut niveau, ou juste un détail subtil de celle-ci. Dans ce dernier cas, vous devez séparer ce test de votre suite de tests d'intégration. Le but des tests unitaires est de localiser les bogues. Ainsi, si vous introduisez un bogue, il y aura un et un seul échec de test.
Avons-nous écrit les histoires de la mauvaise façon?
Je pense que vous avez juste besoin d'organiser vos histoires en épopées soit par utilisateur, par exemple "Client", "Assistant", soit par fonctionnalités / écrans / workflows ("Achat", "Remboursement").
Et encore une fois, les tests de spécification ne remplacent pas les tests unitaires. Lire la suite