CocoaHeads Toulouse - Xcode et les tests - Epitez

8,072 views

Published on

Présentation de Jean-François Marronnier (Epitez) pour la session spéciale Tests d'octobre 2013 aux CocoaHeads Toulouse

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
8,072
On SlideShare
0
From Embeds
0
Number of Embeds
7,334
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CocoaHeads Toulouse - Xcode et les tests - Epitez

  1. 1. XCode & Les Tests ou Des Tests au Code Ekito - Cocoahead Epitez - JF Marronnier
  2. 2. Sommaire
  3. 3. XCode 5 & XCTest Nouvelle interface mettant en évidence les tests  ajout d’un navigateur de tests (Copie d’écran ci dessous) o Contrôle d’exécution o Visualise résultat de test • Nouveau « framework » XCTest • Les projets sont créés systématiquement avec une « cible » test Interface de Tests • Résultat global Cas Test Navigateur de Cas Tests « Ko » • Résultats • Exécution
  4. 4. Tests : Pourquoi tester ? • Trouver les erreurs de codage • Vérifier que l’intégration du système • Vérifier l’adéquation Spécification vs Logiciel • Eviter/Détecter les régressions
  5. 5. Tests : On teste du code Le tests s’exécutent sur du code existant, n’est-ce pas ? Mais : •Imaginerons nous en tests ce qu’il n’a pas vu lors du codage ? •Les bugs seront détectés tardivement (après le codage) •En fin de projet, les budgets sont très limités ceci augment le risque sur les tests et la correction des bugs détectés. •Les tests sont liés au code et peut aux besoins utilisateur
  6. 6. Tests : TDD c’est quoi ? C’est pourquoi que le TDD a été imaginé. L’idée est décrire le tests avant le code. Le code ne réponds qu’aux tests écris. Ainsi : •Le code ne répond qu’aux besoins exprimés ; •Les erreurs sont détectés immédiatement ; •Les tests sont automatiques • Exécutable en permanence • Permet de détecter les régressions ? •…
  7. 7. Tests : TDD c’est quoi ? Le cycle de travail est : 1.Écrire un tests qui est 2.Écrire le code minimal qui rend le 3.Récrire le code pour l’améliorer (« refactoring ») Ecrire test [Test Ko] "Refactore" Coder [Test O k] [test O k] Test Ko Test Ok Test Ok
  8. 8. Tests : Règles de l’Oncle Bob Ne pas oublier les règle de l’oncle Bob (Robert Martin) •Vous n'êtes pas autorisé à écrire de code de production, sauf si c'est pour faire une passe de test unitaire défaut. •Vous n'êtes pas autorisé à écrire plus d'un test unitaire que ce qui est suffisant pour faire faillite, et des erreurs de compilation sont des échecs. •Vous n'êtes pas autorisé à écrire de plus le code de production que ce qui est suffisant pour passer d'une faute de test unitaire.
  9. 9. TDD avec IOs : le MVC Vue Action Utilisateur Modifie Notifie Contrôleur Modifie Modèle
  10. 10. Tester un Modèle Contrôleur -> Modèle Model -> Controller Le contrôleur accède directement à la classe modèle. Le modèle ne connais pas le contrôleur. Il communique avec ses «   clients   » le mécanisme de diffusion NSNotificationCenter. a. Le testeur instancie un objet « modèle » ; b. Il le stimule ; c. Il valide directement les données de cette objet. a. Le testeur instancie un objet model ; s’abonne, comme le contrôleur, au centre de notification du model ; b. Il stimule directement l’objet modèle ; c. Il valide alors les notifications reçues.
  11. 11. TDD avec les Vues
  12. 12. Éléments du Storyboard A partir de la class UIStoryBoard il est possible de charger un «  storyBoard  » à partir de son nom. UIStoryboard * storyboard = [UIStoryboard storyboardWithName:@"Main" bundle:nil]; Du storyBoard on peut récupérer le contrôleur associé. // Pour récupérer le controller initial monViewController * viewController = [storyboard instantiateInitialViewController]; //(ou) pour récupérer un controller par son nom monViewController * viewController = [storyboard instantiateViewControllerWithIdentifier:@"controllerName"];
  13. 13. Tester composants vue Pour respecter le TDD a.Rédiger le test (composant non « nil ») Définir le « IBOutlet » dans le contrôleur  le test est Ko b.Définir le composant dans la vue Le relier avec le « IBOutlet » dans le contrôleur  le test est Ok
  14. 14. Attributs composants Noter que les attributs graphiques des composants peuvent être défini avec le TDD (si ceux-ci sont important pour le client). Par exemple, le texte d’un label doit être verte: a.XCTAssertEqualObjects([[viewController labelXX] textColor], [UIColor redColor], @"Bad label color") b.Définir la couleur dans le storyBoard
  15. 15. TDD avec le contrôleur Noter que l’objectif est de tester le contrôleur « seul ». L’objectif n’est pas de tester ni la vue ni le model. Pour cela, nous allons utiliser des « Mocks ». Plusieurs possibilités: -Faire son propre mock (à la main) -Utiliser un framework (OCMock, Mockito, …)
  16. 16. Notre propre mock Pour cela, je créé une classe qui hérite de la classe à mockée. Je redéveloppe les méthodes utilisées par la fonctionnalité du contrôller testée. Dans ces fonction je sauvegarder les informations que je veux testers (arguments, nombre d’appel, …) Dans le contrôlleur je défini le modèle avec le mock. Pour cela, soit : •Utiliser un constructeur définissant le model Model •modifier l’attribut directement avec SetValue. Contrôleur Mock Model
  17. 17. Intégration continues • Les tests peuvent être lancés en ligne de commande. Cela permet d’exécuter le tests avec jenkins. xcodebuild test –scheme leprojet -destination "name=iPhone Retina (4-inch 64-bit) » • Apple propose une solution. Pour cela il faut une machine sous OSX Server. Et utiliser les « bots ». Le résultat ressemble à :
  18. 18. Références Les sources de la démo sont ici :  https://github.com/tijeff/tddIOSBlink Bibliographie : Test-Driven iOS Developpement de Graham Lee Continous Integration in Xcode Clean Code de Robert C. Martin Refactoring Improving The Design of Existing code de Martin Fowler

×