Discussion :

[Logan Mauzaize]

Oui, mais comment savoir quelle catégorie de tests lancer après une modif ? Comment être sûr que le découpage en catégories est fiable et qu'un test dans une catégorie a priori non liée à la modif en cours ne va pas échouer ? Jusqu'où va cette exécution sélective des tests ? Uniquement sur le poste de dev ? Si le serveur d'intégration continue exécute lui systématiquement toute la suite, ne risque-t-on pas d'avoir des builds très longs et des problèmes de concurrence de commits ?

Pour commencer je dirai que la gestion des tests est une activité 50% pro-active et à 50% réactive. Il ne faut pas oublier que ce n'est qu'une assurance : prévenir le danger et aide à la réparation (diagnostic) en cas de dégâts.
Une métrique suffisamment fiable est la couverture (ex : code, exigence). Cela donne déjà une bonne idée de la pertinence.
Quelque soit le projet je pense qu'il doit être possible de définir au moins deux classes : les tests qui peuvent être exécuter sur le poste et la batterie de test relativement courte. Le "relativement" est important parce qu'il diffère en fonction des processus (habitudes) des équipes, quoiqu'il en soit il faut bien le définir entre membres et s'y tenir. On peut par exemple avoir des tests très rapides (<10s) que l'on peut passer quasiment à chaque bloc écrit et d'autres un peu plus long (1-3min) pour ceux qu'on exécute systématiquement avant de publier son code (commit ou push) sur une branche de dev. Dans la même idée on peut avoir des tests plus longs pour vérifier la stabilité de la branche de dev avant de pousser vers une branche d'intégration (ou autre).

Concernant l'intégration continue, elle peut être dissocié du build. Les tests spécifiques de non-régression venant couvrir des cas similaires de tests plus généraux.

J'ai l'impression que pour beaucoup il ne fait aucun doute qu'on doit avoir une méthode de développement, une politique de gestion de configuration mais pour les tests cela doit se faire tout seul. Alors oui ca peut fonctionner comme on peut faire ses développements à la RACHE, ou sinon il existe quelques bonnes pratiques/méthodes.

Même problème, mais à bien moindre échelle. Une classe va typiquement avoir un ou deux collaborateurs donc la complexité sera limitée. "Mocker à tout va" est d'ailleurs sans doute révélateur d'un problème de design - notre objet en fait probablement trop, il a trop de dépendances.

Quand je parle de "mocker à tout va", je voulais dire que tous les TUs mockent leurs dépendances. Les composants sont tellement isolés qu'on ne teste plus grand chose au final.

Oui, ce sont les bugs à la périphérie ou à la lisière de l'application, à savoir défaillance hardware ou réseau, défaillance de système tiers ou problème de configuration. Il faut des tests d'intégration pour ces cas. En général, j'isole ces composants externes via un wrapper ou adapter et je teste le wrapper en intégration.

T'as vraiment confiance à ce point en ton code pour dire qu'il n'y a pas de bugs dans ton application ?
A chaque fois que tu mockes un système tu fais des hypothèses sur celui-ci. Si c'est la même personne qui code l'application et le TU, elle fera les mêmes hypothèses. Et la communication peut alors être faussé. Le système mocké peut tout aussi bien être un composant externe qu'une classe de ton système plus globale.
Les TUs purs ne testeront jamais les communications réelles interne au système, toutes les dépendances ayant été mockées afin de garantir l'isolation du composant testé.

Le problème étant que plus le TI porte sur un vaste système, plus ces assertions seront nombreuses.

Non pas nécessairement plus d'assertions, mais oui plus d'hypothèses ("assumptions"). Il y a toujours un degré de confiance à avoir. C'est ce qu'apportent les tests plus bas niveau exécutés en amont.

Faut-il les mettre toutes dans le même test au point de le rendre peu lisible ? Dans des tests séparés ?

Applique la même logique que tu appliques à tes TUs. En générale, on fait une grosse initialisation (@BeforeClass), puis on exécute des petits préparatifs (@Before), on exécute le test et les vérifications (@Test), les petits nettoyages (@After) et ensuite on fait le gros ménage (@AfterClass).
Rien ne t'empêche d'avoir une hierachie plus complexe avec un système de poupées russes qui te permettent de réutiliser des initialisations massives. Il ne faut pas non plus négliger tout ce qui est "dump". Cela permet d'avoir un "cache" de systèmes externes pré-configurés, le plus souvent on le réserve à la BDD mais il est possible de le faire pour tout autre type de système.

Et surtout, si un sous-système s est testé par des assertions des TI d'un système S1, faut-il les retester dans les TI de S2 dans lequel s est aussi utilisé ? Si non, comment repérer ces chevauchements ?

Concernant le chevauchement verticale : c'est le cas des TI au-dessus des TU ou les tests spécifiques de non-régression. Pourtant qu'un TI provoque le même scénario de test qu'un (ou plusieurs) TU(s) ne te choquent surement pas ?

Concernant le chevauchement horizontale :

1. La plupart des systèmes (classe, module, etc.) fonctionnent en mode "Maître/Esclaves" car on adopte le plus souvent un modèle en couche. Le TI sera uniquement effectué par le système "Maître", tandis que des TUs seront exécutés sur les "Esclaves" pour vérifier qu'ils fonctionnent correctement selon les spécifications du service. Ce n'est ni plus, ni moins qu'un chevauchement vertical. C'est le même problème avec les APIs que tu intègres dans ton code.
2. Si des systèmes "dialoguent" grâce à un médiateur. C'est au médiateur que revient la charge du TI. Le médiateur étant un "Maître" et les systèmes des esclaves. On retourne encore une fois à un chevauchement verticale.
3. Il existe des systèmes qui "dialoguent" selon un modèle d'auto-gestion. Dans ce cas il y a effectivement un risque de chevauchement. Néanmoins, je reste persuadé que pour un "Use Case" (ou une "User Story") donné(e), il y a toujours l'initiative d'un des deux systèmes. Si les deux peuvent être à l'initiative de l'échange, ce seront des scénarios légèrement différents qui méritent d'être testés par chacun.
   Il est également possible qu'en l'absence de médiateur, il y ait une meta-instance qui en joue le rôle. Par exemple sur un très gros projet, en plus de la spécification de tous les composants, il y avait une spécification "Business". C'était donc le rôle de ce meta-"composant" d'assurer que l'ensemble s'intégrait correctement.

Pour la forme une série d'infographie intéressante sur la livraison continue mais qui aborde de nombreux sujets évoqués ici : http://java.dzone.com/articles/illus...nd-visualizing

[Luckyluke34]

T'as vraiment confiance à ce point en ton code pour dire qu'il n'y a pas de bugs dans ton application ?
A chaque fois que tu mockes un système tu fais des hypothèses sur celui-ci. ...

C'est là le coeur du problème. Tu as complètement raison, tous les développeurs supposent des choses en mockant. Plus précisément, ils supposent que la dépendance mockée est réellement capable d'accepter les valeurs qu'on lui passe en entrée dans le test, ou qu'elle va réellement se comporter de la manière dont on la bouchonne. Mais la plupart des développeurs ne testent jamais que ces suppositions sont vraies.

Or, il est simple de rajouter des tests pour vérifier cela. C'est l'approche Contract Tests. Concrètement, pour chaque supposition faite dans les tests que la dépendance D a le comportement de retourner une valeur v, on crée un test en plus qui spécifie dans quel scénario cela est possible et qui asserte que D retourne bien v. Idem pour les valeurs d'entrée. Et la bonne nouvelle, c'est que les contract tests sont eux aussi des TU. On se contente d'appliquer les bons stimulus à l'objet sans avoir à recréer toute l'étendue de son écosystème.

Une autre manière de s'assurer que ces suppositions tiennent la route est d'utiliser Design By Contract, avec des pré-conditions directement intégrées aux méthodes du code de production. Ainsi, toute supposition utilisant des valeurs d'entrée invalides est immédiatement rejetée par le système à l'exécution (voire à la compilation).

Je ne conseillerais pas cette approche dans tous les cas, mais c'est une bonne manière de faire si on veut avoir une totale confiance dans les couches internes de son code et que la fiabilité du système est importante. En plus, cela évite d'avoir trop recours aux tests d'intégration.

Pourtant qu'un TI provoque le même scénario de test qu'un (ou plusieurs) TU(s) ne te choquent surement pas ?

Non car mes TI sont en général un ordre de grandeur moins nombreux que mes TU et les TU s'exécutent plus vite. Dans un scénario ou la majorité des tests sont des TI qui essaient de couvrir autant que ce qui aurait été couvert par des TU, un chevauchement me parait plus problématique.

cf http://martinfowler.com/bliki/TestPyramid.html