Par contre je n'ai pas compris l'intérêt d'avoir les cas de tests et les résultats attendus dans la doc.
En réalité, ça dépend de quelle doc on parle. Il y a une grande souplesse avec ce système.
Par exemple dans les tests de bbt, j'ai séparé en plusieurs répertoires.
1. les fonctions du logiciel : elles sont dans le répertoire features. Il s'agit en réalité de la totalité des tests d'acceptation. Ce n'est pas une doc utilisateur, qui doit être plus synthétique : ici, il y a plein de cas, y compris des tests de robustesses, et ce n'est pas structuré pour être pédagogique.
2. les exemples : je ne veux pas que la doc donne des tests qui ne marchent plus, à cause d'une typo ou d'une évolution. Le problème est réglé comme ça, les exemples sont dans la suite de tests.
3. les tests de non reg : en réalité ceux la n'ont rien à faire dans le répertoire docs (je vais les remettre dans le répertoire tests). C'est très utile, mais c'est pour les devs, pas pour les utilisateurs.
Et dans le répertoire features, il y un sous répertoire proposed_features, qui permet de discuter de fonction non encore implémentées.
Donc rien n'empêche d'avoir un guide utilisateur avec quelques exemples dans un doc, un cahier de recette avec des tests d'acceptation dans un autre doc, des tests qui ne passent pas encore dans un doc de backlog, etc.
[^] # Re: J'ai compris mais j'ai pas compris
Posté par Lionel Draghi (site web personnel) . En réponse au journal Documenter ou tester, il faut trancher (j'ai pas trouvé de rime avec choisir...). Évalué à 3.
En réalité, ça dépend de quelle doc on parle. Il y a une grande souplesse avec ce système.
Par exemple dans les tests de bbt, j'ai séparé en plusieurs répertoires.
1. les fonctions du logiciel : elles sont dans le répertoire features. Il s'agit en réalité de la totalité des tests d'acceptation. Ce n'est pas une doc utilisateur, qui doit être plus synthétique : ici, il y a plein de cas, y compris des tests de robustesses, et ce n'est pas structuré pour être pédagogique.
2. les exemples : je ne veux pas que la doc donne des tests qui ne marchent plus, à cause d'une typo ou d'une évolution. Le problème est réglé comme ça, les exemples sont dans la suite de tests.
3. les tests de non reg : en réalité ceux la n'ont rien à faire dans le répertoire docs (je vais les remettre dans le répertoire tests). C'est très utile, mais c'est pour les devs, pas pour les utilisateurs.
Et dans le répertoire features, il y un sous répertoire proposed_features, qui permet de discuter de fonction non encore implémentées.
Donc rien n'empêche d'avoir un guide utilisateur avec quelques exemples dans un doc, un cahier de recette avec des tests d'acceptation dans un autre doc, des tests qui ne passent pas encore dans un doc de backlog, etc.