les tests automatisés
Salut,
avez-vous déjà utilisé des tests unitaires automatisés? Je vois parfois ça dans les offres d'emplois pour développeur ios, certains demandent des connaissances en tests automatisés, et je viens de tomber sur un petit papier de blog qui en parle avec quelques exemples de sources... mais ... est-ce bien nécessaire? Pour les plus expérimentés, est-ce un aspect qu'il vaut mieux maà®triser dès maintenant? Ou c'est quelque chose d'assez peu utilisé au final pour le mettre dans sa liste de choses importantes à apprendre?
Merci 
Edit: au final, ces tutos m'ont bien aidé : http://www.raywenderlich.com/22816/beginning-automated-testing-with-xcode-part-22
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tous nos projets iOS dans ma boite ont des TU pour tous les WebServices (c'est un peu obligatoire vu qu'en général quand on code l'appli iOS on n'a que des bouchons pour les WS et que l'intégration 2-à -2 de ces WS se fait + tard, donc faut être prêt à débouchonner sans que tout casse).
Et ils sont tous sous Jenkins, notre serveur d'intégration continue, qui compile et lance les tests unitaires automatisés à chaque fois que qqun pousse un commit, et nous envoie un mail s'il y a des tests qui ont cassés ou des régressions.
Pour la plupart des débutants, bcp pensent que "les TU ça sert à rien". Pourtant même si ça prend un peu de temps de les écrire, ça gagne bcp de temps en debug, en VABF et correction d'anomalies, et ça évite de faire des régressions, et au final c'est donc primordial.
On n'en est pas encore à appliquer des méthodos de type RGR (Red-Green-Refactoring) sur nos projets (quoiqu'on l'a fait pour certains), mais on s'engage à avoir une couverture de code ("code coverage") des classes métier de 80% minimum (= 80% de notre code ou + est couvert par des tests unitaires, y compris tous les cas possibles genre le cas du "if" mais aussi celui du "else", etc).
Il me semble qu'il y a déjà des threads sur le sujet dans le forum, d'ailleurs.
Merci, d'accord, je vais faire un tour sur les sujets du forum,
qu'est-ce que ça veut dire ça : "on n'a que des bouchons pour les WS et que l'intégration 2-à -2 de ces WS se fait + tard" ?
Sinon, comment ça se passe concrètement quand plusieurs développeurs travaillent sur un projet? Dans mes différents tests d'applis pour apprendre, tout se fait souvent dans la même classe, est-ce que tu as un exemple de ce que font les uns et les autres sur un projet concret?
Merci
Après, dans une vraie application, il faut prévoir la mise en place de TU dés la phase de conception, car un mauvaise conception rendra la mise en place de TU difficiles.
D'ailleurs, en ce qui me concerne, je recommande fortement de suivre au maximum les concepts "SOLID" ( http://fr.wikipedia.org/wiki/SOLID_(informatique)) ) qui conduisent à du code très modulaire et facilement testable (notamment en permettant de remplacer facilement certaines objets par des bouchons grâce au couplage faible entre classes).
Et un "bouchon" c'est généralement un objet qui vient remplacer l'objet réel de l'application pour en simuler le comportement. Par exemple, quand tu développes une classe permettant d'accéder à un Web Service mais que ce Web Service n'est pas encore prêt, dans les TU on remplace cette classe par un "bouchon" qui va simuler le comportement du web service et va permettre de tester les autres briques du logiciel comme si le WS était réellement disponible.
Sinon, Dans Xcode il y a tout ce qu'il faut pour gérer les TU. Et sans aller jusqu'à installer un Jenkins, les développeurs iOS enregistrés chez Apple ont droit à OSX Server gratuit, qui intègre Xcode server, l'outil le plus simple pour automatiser l'exécution des TU et la production de livrables...
OK, merci, il y a les Behavior-driven-development (BDD), les TDD, sur ce site , et autres tests unitaires, je sais pas trop par où commencer, peut-être est-ce que je vais mettre ça de côté dans un premier temps... merci de vos réponses
Commence par les tests unitaires, c'est la base.
Et sous XCode, il suffit de créer un nouveau fichier par File > New > File > Test Case Class pour tester.
cherche sur le forum y a pleines de discussions sur les tests unitaires/fonctionnels
http://forum.cocoacafe.fr/topic/9747-les-tests-unitaire-et-vous/page-2?hl=tdd
http://forum.cocoacafe.fr/topic/10098-verifier-la-qualite-du-code-produit/?hl=tdd#entry96909
....
J'ai vu récemment les vidéos traitant des tests au WWDC 2015 et plusieurs choses ont éveillé un intérêt tout particulier.
J'ai très peu d'expériences sur le sujet des tests c'est pourquoi je me suis intéressé dessus et dans les nouveautés je vois pas mal de choses qui règles des points qui me bloquaient auparavant.
Un petit exemple, je souhaitais tester des fonctions mathématiques dans un projet malheureusement du fait de l'encapsulation de celles-ci, par défaut internal en Swift, je n'y avait pas accès dans mes tests. Pour résoudre le problème, j'avais lu qu'il fallait passer ces méthodes en public. Quand je lis ça personnellement ça me donne pas envie de continuer les tests.
Heureusement, Apple intègre un nouveau mot clé testable qui permet de tester d'autres modules.
Autre chose aussi, c'était tester l'interface et les cas d'utilisations. Je trouvais pas ça particulièrement agréable de tester l'UI mais avec ce qu'ils ont montré je trouve ça énorme. D'une part ils ont implémentés de nouvelles classes (de tête XCUIApplication, XCUIElementQuery et XCUIElement) qui permettent de récupérer et d'interagir avec les éléments d'interface mais surtout, d'après la vidéo on peut enregistré les cas d'utilisation et le code est automatiquement généré.
Il y a aussi le panel pour le code coverage qui permet de voir si on a bien tout testé et qui colle à plusieurs pratiques de tests ce qui donne une bonne vision globale de ce qui reste à faire, ce qui marche et ne marche pas. Il y a tout pleins de choses encore que j'ai du oublié mais j'ai l'impression qu'un effort important a été fait sur ce côté.
Vous en pensez quoi ?
J'en pense qu'il faudra bientôt 15 ans d'apprentissage pour être développeur iOS, tellement il y a de nouvelles choses à connaà®tre.
Sinon j'aime beaucoup l'idée des tests automatisés d'interface.
Tester consiste à injecter des données en entrée et vérifier le résultat en sortie. Or, ceci va à l'encontre du principe d'encapsulation de la programmation objet: on cherche à cacher le fonctionnement interne.
Dans ton exemple, ce qu'il faut faire est extraire ces fonctions mathématiques dans une nouvelle classe; ces fonctions seront effectivement publiques. Ainsi, tu vas pouvoir exercer cette classe indépendamment et directement (pas à travers l'autre classe). La classe dont a été extrait le code s'appuiera sur cette nouvelle classe *en interne*.
Ceci est un peu contraignant, mais ça force à créer de *petites* classes dont le rôle est *bien défini*. Au final, le code sera plus simple, plus souple et plus réutilisable.
Je conseille à tout programmeur de se mettre au Test Driven Development. C'est un très bon moyen de progresser, et de vraiment améliorer la qualité du logiciel.
Je trouve ça intéressant. On a enfin l'outil attendu, et plus ce bricolage affreux qu'est UIAutomation, avec sa syntaxe dégueulasse en JavaScript, et la nécessité de lancer Instruments. De toute façon personne ne l'utilisait, parce que ça fonctionnait très mal, et on ne pouvait pas le lancer sur la machine d'intégration.
Mais... le code de test doit être maintenu. Alors, moi je vois bien dans la démo que ça pond des dizaines de lignes de code automatiquement, mais il faudra voir dans la vraie vie si on pourra mettre à jour facilement les scénarios de test, tout en s'assurant qu'on attrape bien les régressions.
Oui, j'ai crié " Alleluia ". ça existe depuis 15 ans dans le monde Java.
Je suis d'accord. D'ailleurs cet effort a débuté avec Xcode 5. Le monde Cocoa est terriblement à la traà®ne pour tout de ce qui est tests, et c'est en grande partie la faute d'Apple qui n'a pas créé les outils, même pas pour ses propres équipes. C'est une bonne chose pour nous mais aussi pour les clients d'Apple: on ne peut plus faire l'impasse sur la qualité.
Effectivement mais je dois dire que je trouvais ça hyper chiant de changer ça. Maintenant au moins ce sera plus facile.
Pour le TDD j'ai lu beaucoup d'articles dessus et je pense suivre tes conseils en l'appliquant dans de futurs projets. J'ai vu des méthodes qui allaient jusqu'à tester les codes de test. Je comprends à moitié. Si on test nos tests, ça n'en finira jamais en principe. À quel moment décide t-on de terminer ?
Peut-être que ces nouvelles fonctionnalités vont démocratiser les tests qui sait.
- s'assurer que la fonctionnalité est là .
- s'assurer qu'on n'a pas commis d'erreur.
À partir de là , il faut utiliser ta tête et ton expérience:
- Est-il utile de tester des accesseurs générés par des propriétés ? Non. (on fait confiance au compilo).
On a surchargé le setter ? Alors oui. (on a pu se tromper).
- Doit-on tester avec toutes les valeurs d'une variable utilisée dans une boucle ? Non. On sait que les erreurs courante de comptage c'est de se tromper d'une unité. Si ça doit compter de 0 à 100, on essaie avec -1, 0, 1 et 99, 100, 101. C'est un exemple.
Comme je l'écris plus haut, la maintenance du code de test représente beaucoup de travail. Normalement, on a à peu près autant de code de test que de code fonctionnel. Alors il faut chercher le retour sur investissement.
Suis ton instinct: tu dois être capable de dire si tu as confiance en ton code ou non. Si tu n'as pas confiance, c'est qu'il n'est pas suffisamment couvert.
ça marche ! Je pense qu'il y a beaucoup à apprendre sur ce sujet. Mercii pour tes conseils.
Les tests ne sont pas la que pour confirmer que ton code marche bien au présent, mais aussi pour s'assurer la le code fonctionnera dans le futur avec toutes les nouvelles modifications.
Je ne pense pas que les tests vont à l'encontre du principe de l'encapsulation, parce que généralement on teste que l'API publique et biensur en testant cette dernière on testera forcément les fonctions internes (puisque l'API publique se base sur les fientions internes).
1) Ceux qui disent qu'il faut tout tester, donc y compris les méthodes privées
2) Ceux qui disent qu'il ne faut tester que les méthodes publiques, car les méthodes privés ne sont que des détails d'implémentation
3) Ceux qui sont un peu entre les deux (genre moi ) où on teste surtout les méthodes publiques uniquement, et on fait une exception parfois quand on sait qu'une méthode privée est clé, genre un algo qui est au coeur du système et est assez central pour l'appli, même s'il n'est pas exposé publiquement.
Evidemment, si tu es de l'école (1), pour tester les méthodes privées t'as des problèmes, soit tu dois les rendre publiques, soit avec Swift 1 tu peux utiliser @testable pour résoudre le problème
Si tu es de l'école (2), finalement tu n'as pas de problème car tu ne testes que ce qui est public.
L'idée derrière les avocats de l'école 2, c'est de dire, imagine que tu as par exemple :
- une fonction privée "triple(x)" qui retourne "3*x"
- une méthode "p1(x)" qui retourne "triple(x)+2"
- une méthode "p2(x)" qui retourne "triple(x)+x"
Vu que triple(x) est privée, c'est un peu un détail d'implémentation. Est-ce vraiment nécessaire de la tester elle-même, alors que ce qui est le plus important finalement c'est que p1 et p2 retournent le bon résultat, quelle que soit leur implémentation.
Si demain tu changes l'implémentation de p1 pour que ça retourne "x+x+x+2" et celle de p2 pour que ça retourne "4*x", p1 et p2 continueront de fonctionner comme attendu, de retourner les mêmes résultats en sortie pour les mêmes données en entrée, leurs tests continueront de fonctionner. Et du coup qu'est ce que tu t'en fiches de triple(x) qui du coup ne sera plus utilisée par personne ?
L'école 3 étant entre les deux, dit que "en général l'école 2 a raison, mais y'a quand même des fois où on sait que y'a une 30aine de méthodes publiques qui dépendent de ta méthode privée "supercalcul(x)" et donc que ça peut être quand même intéressant de tester supercalcul(x) (histoire que si tes 30 méthodes publiques foirent, tu vois si c'est parce qu'en fait c'est supercalcul lui-même qui est tombé en panne ou bien si supercalcul marche toujours et que ça vient d'autre part. Et du coup @testable peut être utile dans ces cas d'exception
---
Faire du TDD t'oblige à exposer tes méthodes que tu auras besoin de tester, et à garder en privé tout ce qui n'est qu'un détail d'implémentation de toute façon et que tu n'auras pas besoin de tester. L'avantage du TDD c'est que ça te fait te poser la question de "finalement, qu'est ce qui m'importe dans mon application, quel est juste le strict minimum qui me permet de dire "ok bon application fait ce pour quoi elle est prévue" ? Et au final, bah ça... ce sont tes spécifications fonctionnelles finalement !
Un de mes profs m'avait donné un exemple qui m'a toujours fait marrer :
- Il nous avait dit "Vous avez à faire un jeu où on donne un nombre en entrée, et dont la règle du jeu est on ne peut plus simple : les specs sont " Quand le nombre est plus grand que 100, vous avez gagné ".
- Le but de l'exercice était alors d'implémenter la fonction "hasWon() -> Bool" qui dit si tu as gagné.
Evidemment, tout le monde a écrit des trucs comme "if (points > 100) return true; else return false" etc.
Sa réponse ? " Vous avez tous fait bien compliqué, voilà ma solution : "return true" "
Nous : " Mais Monsieur, votre fonction elle ne marche pas, elle retourne true même quand on n'a perdu !"
Lui : " Mais qui a dit qu'il fallait retourner false quand on a perdu ? On a juste dit qu'il fallait retourner true quand on a gagné, on a pas dit ce qu'il fallait retourner quand c'était pas le cas !"
Bon, évidemment, c'est un exemple exagéré exprès. Mais le but était de montrer que bien souvent en commençant par l'implémentation (plutôt que commencer par écrire les tests qui traduisent juste les specs et rien d'autre comme on fait en TDD), on a tendance à implémenter des trucs inutiles, à imaginer des cas qui en pratique n'arriveront jamais, à supposer des trucs alors que ça n'a pas du tout été spécifié, etc... bref à faire du boulot pour rien...
Je trouve encore l'anecdote amusante, et elle montre aussi l'esprit du TDD, à savoir utiliser les tests pour t'aider à spécifier ton application, et n'implémenter qu'ensuite, et comme ça en + ton implémentation est forcément testable, par définition, puisque tu l'as construite ainsi !
T'as pas compris, en fait il voulait éviter d'écrire un nombre magique dans le code.
Je ne vais pas poursuivre cette discussion, parce que là , on rentre dans des considérations sur des détails. Dans un premier temps, ce qui est important, c'est de se mettre au TDD, après on en tire ses propres conclusions.
L'exemple d'Aligator est parfait pour démontrer l'utilité ou pas de tester les méthodes privées.
Quand on dit "Quand le nombre est plus grand que 100, vous avez gagné" on comprend implicitement que quand le nombre est inférieur à 100, on a perdu.
Un des objets du TDD est justement d'expliciter tous les comportements attendus :
- d'accord monsieur le client, plus grand que 100 c'est gagné, et donc plus petit que 100 c'est perdu ? et égal à 100 c'est gagné ou c'est perdu ?
Pour les méthodes privés, je pense qu'on est dans le même ordre d'idée. S'il y a des comportements implémentés dans les méthodes privées qui ne sont pas visibles d'une façon ou d'une autre de l'"extérieur", c'est que ces comportements ne sont pas explicitement spécifiés, et donc :
- soit il n'y a pas lieu de les tester (exemple d'Aligator)
- soit il faut expliciter le comportement attendu (et donc le tester)
Les gens normaux sont imprécis quand ils s'expriment. Il faut s'y faire.
Pour eux il est évident que si "supérieur à 100" gagne, alors "inférieur à 100 perd" donc ils ne pensent pas à le dire.
Du coup, ils ne pensent pas non plus au cas "égal à 100" et à l'ambiguité qu'il va poser pour une machine (ou un développeur) s'ils ont oublié de préciser "supérieur strictement" ou "supérieur ou égal".
Ces imprécisions sont parfois à l'origine de quiproquo et d'incompréhensions, mais elles permettent aussi de communiquer rapidement. Si on devait tout spécifier à fond, alors on ne pourrait pas se dire grand chose, on ne pourrait pas communiquer en fait, puisqu'il n'y a pas de limites à la "précision" qu'on peut atteindre quand on décrit la réalité.
En tant que développeur, nous sommes en général plus sensibles aux manques de précision. On peut même dire que parfois, cela nous stresse de ne pas avoir plus de détails sur ce qu'il faut faire dans telle situation, ou sur ce qui va se passer dans tel cas.
Du coup, le TDD, c'est bien, mais uniquement dans un cadre Agile où on a le client sous la main.
Quand on est en waterfall, avec un client qu'on ne voit que tous les 15 jours, il vaut mieux ne pas attendre l'écriture des tests unitaires pour lever les ambiguités.
Dans ce cas, il faut reformuler dans la discussion avec le client (ou poser des tas de questions pendant la relecture des specs). Par exemple :
"-Quand vous dites "supérieur à 100", vous voulez dire "supérieur ou égal à 100", n'est ce pas ?
-Ah ben oui bien sûr ! 100 gagne et tout ce qu'il y a au-dessus aussi."
Ceci dit la blaque du prof est débile car elle incite à prendre les specs au pied de la lettre, plutôt qu'à les analyser et à communiquer avant de coder. en plus c'est un exemple où il n'y a pas de réelle ambiguité (sauf sur la valeur 100) donc "il joue au con".
Non, ce n'est pas débile du tout. L'interprétation c'est le mal !
J'insiste constamment auprès des développeurs chez mes clients pour systématiquement remplacer l'interprétation par le questionnement, de leur client en agile, ou de l'architecte ou du concepteur en waterfall.
Je ne partage pas ton analyse. Pour moi, la blague du prof était justement destiné à provoquer une réaction d'un élève lors de l'exposé du problème. Il m'est arrivé une expérience similaire avec un prof d'électronique un jour. On est tous tombé dans le panneau, à la grande déception de l'enseignant.
Et rien n'empêche d'envoyer un mail au client, avec une série de questions sur les points obscurs. Si possible en lui demandant de choisir parmi plusieurs solutions.
Absolument. D'où le besoin de poser des questions, même sur des sujets "évidents" pour vérifier si le développeur est sur la même longueur d'ondes que le client.
Donc au contraire, cet exemple pourtant simple a montré bien plus de choses que tu ne penses, et justement entre autres qu'il ne faut jamais "supposer" et penser que des trucs sont "évidents" : cette anecdote nous a aussi justement servi à nous apprendre qu'il faut mieux discuter avec le client et lui poser des questions.
Si c'était vécu comme ça, alors ok.