XCode & Les Tests
ou
Des Tests au Code
Ekito - Cocoahead
Epitez - JF Marronnier
Sommaire
XCode 5 & XCTest
Nouvelle interface mettant en évidence les tests
 ajout d’un navigateur de tests (Copie d’écran ci
desso...
Tests : Pourquoi tester ?
• Trouver les erreurs de codage
• Vérifier que l’intégration du système
• Vérifier l’adéquation ...
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...
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é...
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écrir...
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 d...
TDD avec IOs : le MVC
Vue

Action
Utilisateur

Modifie

Notifie

Contrôleur

Modifie

Modèle
Tester un Modèle
Contrôleur -> Modèle

Model -> Controller

Le contrôleur accède directement à la classe
modèle.

Le modèl...
TDD avec les Vues
Éléments du Storyboard
A partir de la class UIStoryBoard il est possible de charger un «  storyBoard  » à
partir de son no...
Tester composants vue
Pour respecter le TDD
a.Rédiger le test (composant non « nil »)
Définir le « IBOutlet » dans le cont...
Attributs composants
Noter que les attributs graphiques des
composants peuvent être défini avec le TDD (si
ceux-ci sont im...
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...
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 pa...
Intégration continues
• Les tests peuvent être lancés en ligne de
commande. Cela permet d’exécuter le tests
avec jenkins.
...
Références
Les sources de la démo sont ici :
 https://github.com/tijeff/tddIOSBlink
Bibliographie :
Test-Driven iOS Deve...
Prochain SlideShare
Chargement dans…5
×

CocoaHeads Toulouse - Xcode et les tests - Epitez

8 034 vues

Publié le

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

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
8 034
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7 329
Actions
Partages
0
Téléchargements
12
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

×