Les tests depuis le téléphone, critères de couverture compris
Six niveaux de tests, les critères de couverture des instructions à MC/DC, et pourquoi avoir les résultats sur le téléphone est un avantage.
L'onglet Projet → Tests n'est pas seulement une liste de ce qui échoue. C'est l'endroit où vous commandez des tests, lisez leur historique et passez d'un cas en échec à ce qu'il vérifie réellement — et tout cela depuis le téléphone, sans une seule ligne de prompt.
Niveaux
Les tests sont répartis en six niveaux : unitaires, d'intégration, système, E2E, performance de l'interface et performance du backend. Ils se changent en haut et chacun garde son propre historique d'Exécutions.
Cette répartition n'est pas cosmétique. Un test unitaire en échec ne signifie pas la même chose qu'un E2E en échec — et quand vous voyez les deux dans une seule liste, vous perdez justement l'information pour laquelle les niveaux existent.
Critères de couverture — et pourquoi au fond
Quand vous commandez des tests par la phrase « écris des tests », vous obtenez des tests. La question est ce qu'ils vérifient — et personne n'a de réponse à cela jusqu'à ce que quelque chose tombe en production.
Un critère de couverture est une règle qui dit quand il y a assez de tests. Ce n'est pas un pourcentage ; c'est une phrase qu'on peut vérifier :
- Couverture des instructions
- Chaque instruction s'exécute au moins une fois. Le moins cher et le plus faible — le code a tourné, mais de ses branches cela ne dit rien.
- Couverture des branches
- Chaque condition sort une fois vraie et une fois fausse. C'est là que les tests commencent à trouver des erreurs.
- MC/DC
- Pour chaque sous-condition, on montre qu'à elle seule elle change le résultat. Cher, mais pour les conditions composées c'est le seul moyen de découvrir que l'une d'elles est en trop.
- Pair-wise
- Chaque paire de valeurs de caractéristiques différentes se rencontre dans au moins un test. Une fraction des combinaisons, la majorité des erreurs.
Dans l'application vous choisissez le critère au moment de commander les tests et vous voyez à quel point il est exigeant — avant que l'Agent se mette au travail. C'est la différence avec « écris des tests » : vous savez ce que vous allez obtenir, et l'Agent sait quand s'arrêter.
Faites établir par l'Agent le panorama des critères pour votre projet. Il précisera pour chacun à quel point il est exigeant précisément ici — ce n'est pas la même chose pour un analyseur que pour un formulaire.
Pourquoi l'avoir sur le téléphone est un avantage
- Les résultats se lisent aussi sans connexion. Les Exécutions sont téléchargées, vous pouvez donc fouiller dedans même en avion.
- D'un cas en échec part un lien vers sa description dans la documentation et vers une capture d'écran de l'instant de la chute. Pas vers cent lignes de journal.
- L'historique à travers les Exécutions révèle un test instable — celui qui passe une fois et pas la suivante. Dans un terminal vous vous en souvenez, ici on le voit.
- Les valeurs mesurées dans les tests de performance ont une évolution à travers les Exécutions. Un seul nombre ne dit rien d'une mesure, la direction si.
- Commander d'autres tests, c'est quelques appuis, pas l'écriture d'un prompt. On choisit le niveau et le critère, l'Agent fait le reste.
D'où viennent les résultats
L'application lit du JUnit XML, c'est-à-dire le format que presque tous les outils de test savent cracher. L'Agent l'écrit dans le projet et le téléphone le télécharge avec le miroir — aucun service entre les deux, aucun envoi où que ce soit.
La forme dans laquelle les résultats sont écrits est fixée par un skill applicatif. Les skills se posent dans le projet depuis l'onglet Projet, section Skills applicatifs ; sans eux vous ne verrez que ce qui est déjà dans le projet.
Ça a coincé ailleurs que ce qui est ici ? Écrivez à support@coden-app.com.