Tester au plus proche de l’interface avec les BDD et l’architecture MVVM
Pour tester les interfaces de nos applications, nous avons tendance à nous ruer sur les tests d’interfaces, or ce n’est pas la solution idéale.
Les tests d’interfaces sont lents, rigides et fragiles.
- Lent : quelque soit la solution technique choisie, un test d’interface prend le temps irréductible de son exécution. Ils ne sont pas forcement compatibles avec un industrialisation complète (ex. : une exécution déclenchée au commit). De plus, la lenteur d’exécution les rend intrinsèquement lents et laborieux à rédiger.
- Rigide : le test d’interface n’apprécie pas le changement, leur maintenance est chronophage.
- Fragile : nous en avons tous fait l’expérience, une execution réussie et complète n’est jamais garantie.
La solution est donc de limiter leur nombre et de les utiliser à bon escient. Identifier et écrire un ou deux tests d’interface pour un ou deux parcours clés (KeyFeature). Ces parcours clés sont la raison d’être de votre application. Pour une application de commerce : testons de la mise au panier au paiement.
Pour tester les autres éléments d’interfaces, les BDD (Behavior-Driven Development) sont une alternative crédible. Reprenant le meilleur des tests unitaires et des tests d’interface, rapides et robustes, ils permettent de tester la bonne intégration des différentes couches tout en se positionnant juste sous l’épiderme de notre application : l’interface.
Alliée à une architecture MVVM, il est facile de tester des éléments d’interface à l’aide des BDD.
Un BDD peut tester la dynamique UI :
- d’un changement de couleur ou d’image
- d’un positionnement ou d’une contrainte
- d’un segue ou de l’apparition d’un popup
En voici un exemple simple, dont les sources sont disponibles sur Github.
Comme toujours, nous partons du besoin avec un exemple illustrant une règle simple : Après la saisie d’un chiffre, si l’utilisateur clique sur le bouton, le bouton devient :
- rouge si le chiffre est pair
- vert si le chiffre est impair.
Pour plus de détails sur le parsing et l’exécution de cet exemple vous pouvez vous reporter à l’article précédent :
Pour initier le développement de notre ViewModel, nous identifions sur notre exemple nos entrées et notre sortie : 2 entrées (un champ de saisie et le clique sur le bouton) et 1 sortie (la couleur du bouton).
Notre ViewModel est donc :
Notre test devient passant. Il nous faut un second exemple pour finaliser.
Nous développons la méthode getEvaluateColorDriver() pour que ce test soit passant.
Il nous reste à créer le ViewController et à le binder à ce ViewModel.
Notre fonctionnalité est terminée et testée.
Finalement, cet exemple nous montre que les BDD peuvent être un complément crédible aux tests d’interfaces.
Quelques tests unitaires sur les cas aux limites (valeur nil etc …) pour compléter notre dispositif et voici une stratégie de test pragmatique et cohérente.
Enjoy ! ;-)
Tous ces principes ont été mis en place et éprouvés dans la vraie vie sur nos dernières réalisations :
