La DI n’est pas de la gruge non. Mais c’est le niveau 0 de ce dont tu as besoin pour tester ta UI. Tu vas très vite avoir des problèmes assez fondamentaux de performance si tu gruges pas.
Ça va tres vite finir trop technique/pointu pour une discussion linuxfr, mais mon example de base, c’est l’interaction avec les boutons, ou n’importe quel component. T’as 2 options, soit tu fait ça propre, et tu génères le touch event qu’il faut pour effectivement taper le bouton, soit tu gruges, et ton test appelle directement l’IBAction qui est censée être liée au bouton (encore que, pour les boutons, tu peux faire ça propre, mais pas pour les table view ou beaucoup d’autre components très courants).
La première option va te donner des test flakys, et très, très, très lent. Trop lent pour espérer scaler.
La deuxième option va te donner des résultats fiables et très rapides. Mais tu testes pas exactement ce que tu voudrais. Et techniquement, tu peux te prendre une régression sur le lien entre le bouton et l’ibaction. En pratique, cette régression a très très peu de chance d’arriver, c’est un risque acceptable, et qui te permet de valider des choses qui elles, ont des chances non négligeable d’arriver.
C’est quelque chose que j’ai finit par accepter, les testes doivent d’abord être fiables, ensuite rapide, et ensuite fidèle/précis, dans cet ordre. Si la précision ne te permet pas d’être fiable et rapide, il faut réduire la fidélité/précision.
[^] # Re: Tests différents (ou partiels)
Posté par groumly . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
La DI n’est pas de la gruge non. Mais c’est le niveau 0 de ce dont tu as besoin pour tester ta UI. Tu vas très vite avoir des problèmes assez fondamentaux de performance si tu gruges pas.
Ça va tres vite finir trop technique/pointu pour une discussion linuxfr, mais mon example de base, c’est l’interaction avec les boutons, ou n’importe quel component. T’as 2 options, soit tu fait ça propre, et tu génères le touch event qu’il faut pour effectivement taper le bouton, soit tu gruges, et ton test appelle directement l’IBAction qui est censée être liée au bouton (encore que, pour les boutons, tu peux faire ça propre, mais pas pour les table view ou beaucoup d’autre components très courants).
La première option va te donner des test flakys, et très, très, très lent. Trop lent pour espérer scaler.
La deuxième option va te donner des résultats fiables et très rapides. Mais tu testes pas exactement ce que tu voudrais. Et techniquement, tu peux te prendre une régression sur le lien entre le bouton et l’ibaction. En pratique, cette régression a très très peu de chance d’arriver, c’est un risque acceptable, et qui te permet de valider des choses qui elles, ont des chances non négligeable d’arriver.
C’est quelque chose que j’ai finit par accepter, les testes doivent d’abord être fiables, ensuite rapide, et ensuite fidèle/précis, dans cet ordre. Si la précision ne te permet pas d’être fiable et rapide, il faut réduire la fidélité/précision.