6. Et puis un jour…
Développer avec le debugger devient un frein
Debugger d’Xcode peu efficace (pas
d’évaluation, variables non accessibles)
Faire du pas à pas dans le simulateur n’est pas productif
Comment détecter les impacts quand on refactor une
méthode ?
7. Il se rend compte que :
Les tests unitaires sur iOS finalement ça marche
Et ça fait gagner du temps
8. C’est quoi le test unitaire de cette session ?
Sortirez vous d’ici prêt à écrire au moins un test d’ici la fin de
l’année ?
9. AGENDA
Quel framework choisir ?
Un test simple
Où tester ?
Cas réel : appel de Web Service
Pour aller plus loin
Conclusion
10. Retour d’expérience
Des projets de bout en bout en TDD avec 3 différents
Framework :
OCUnit
GTM
GHUnit
11. OCUnit, les pour
Intégré à Xcode
Stable
Pas de configuration
Se lance avec un raccourci clavier
12. OCUnit, les contre
Utilisation d’un bundle différent de l’application
Points d’arrêt en dehors des classes de tests
Impossible de lancer un seul test
Lance les tests en même temps que l’application
13. OCUnit, test de recette
Given :
developper.level = kBeginner;
developper.objectives = kLow;
When
Framework *result = [develepper chooseUnitTestingFramework];
Then
assertThat(result, equalTo(OCUnit));
14. GTM, les pour
Target d’application pour les tests
Bien intégré à Xcode
Communauté active
Peu de limitations
15. GTM, les contres
Logs très difficilement exploitables
Ne gère pas bien les exceptions
16. GTM, test de recette
Given :
developper.level = kHigh;
developper.objectives = kHigh;
When
Framework *result = [develepper chooseUnitTestingFramework];
Then
assertThat(result, equalTo(GTM));
17. GHUnit, les pours
Supporte les test écrits pour OCUnit et GTM
Logs sexy
Possibilité de lancé les tests individuellement
Très simple à mettre en place
18. GHUnit, les contres
Pas d’intégration à Xcode
Difficilement automatisable
S’exécute dans context de l’application sur un autre
Thread
Tried to obtain the web lock from a thread other than the main
thread or the web thread. This may be a result of calling to
UIKit from a secondary thread. Crashing now...
19. GHUnit, test de recette
Given :
developper.level = kMedium;
developper.objectives = kMedium;
When
Framework *result = [develepper chooseUnitTestingFramework];
Then
assertThat(result, equalTo(GHUnit));
20. AGENDA
Quel framework choisir ?
Un test simple
Où tester ?
Cas réel : appel de Web Service
Pour aller plus loin
Conclusion
34. Où tester ?
Controller Service ASI
-(void) loadArticlesFrom:To:
Préparation de
la requete
-(void) startAsynchronous
-(void) requestFinished:
Traitement de la
réponse
-(void) service:didSucceedWithArticles:
35. Où tester ?
Préparation de la requête :
Est ce que la bonne url est appelée avec les bons paramètres ?
Est ce que les bons paramètres sont envoyés dans le body ?
Eventuellement validation des paramètres
36. Où tester ?
Traitement de la réponse :
A partir du JSON est ce que j’alimente bien les objets de mon
modèle ?
Les règles et la logique de traitement des articles est respectée ?
• Si le status de l’article est … alors …
Si je reçois des liens est ce que je télécharge bien les données ?
• Images, pdf, etc
37. Où tester ?
Chaine globale :
Est ce que j’appelle bien ASI ?
Est ce que je reçois la réponse de ASI ?
Est ce que j’appelle bien la méthode didSucceed / didFail de mon
delegate ?
38. AGENDA
Quel framework choisir ?
Un test simple
Où tester ?
Cas réel : appel de Web Service
Pour aller plus loin
Conclusion
39. Tests des méthodes privées
Test Service
-(Request*) requestForArticles
Préparation de
la requete
-(NSArray*) parseData:(NSData*)
Traitement du
retour
43. Tests des méthodes privées
Créer des méthodes qui prennent des paramètres simples
à créer dans vos tests
Créer des méthodes qui retournent des objets simple à
tester dans vos tests
Gérer l’asynchrone en dehors de ces méthodes
Pour plus d’informations voir le pattern « dependency
injection »
http://spin.atomicobject.com/2010/12/09/objection-dependency-injection-in-obj-c/
48. AGENDA
Quel framework choisir ?
Un test simple
Où tester ?
Cas réel : appel de Web Service
Pour aller plus loin
Conclusion
49. Pour aller plus loin
Une autre session ?
OCMock
Tests des méthodes assynchrones
CoreData
50. AGENDA
Quel framework choisir ?
Un test simple
Où tester ?
Cas réel : appel de Web Service
Pour aller plus loin
Conclusion
51. Conclusion
Privilégiez un Framework simple à un Framework complet
Peu de tests vaut mieux que pas de tests du tout
Dans certains cas développer en TDD est plus productif
qu’avec le simulateur
Modifier légèrement votre code pour créer des
situations faciles à tester
52. Take away
Pour récapituler :
Sortez la logique de vos controller
Identifier le code que vous souhaitez tester
Sortez le dans une méthode spécifique
Faites en sorte que cette méthode soit simple à tester