Upload
cocoaheads-france
View
6.698
Download
0
Embed Size (px)
DESCRIPTION
Présentation de Jean-François Marronnier (Epitez) pour la session spéciale Tests d'octobre 2013 aux CocoaHeads Toulouse
Citation preview
XCode & Les Testsou
Des Tests au CodeEkito - 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 dessous)o Contrôle d’exécutiono Visualise résultat de test
• Nouveau « framework » XCTest• Les projets sont créés systématiquement avec une « cible »
test
Navigateur deCas Tests « Ko »
Cas Test
Résultat global
• Résultats
• Exécution
Interface de Tests
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
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
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 ?
•…
Tests : TDD c’est quoi ?
Le cycle de travail est :
1.Écrire un tests qui est Test Ko2.Écrire le code minimal qui rend le Test Ok3.Récrire le code pour l’améliorer (« refactoring »)Test Ok
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.
TDD avec IOs : le MVC
Tester un ModèleContrôleur -> Modèle Model -> Controller
Le contrôleur accède directement à la classe modèle.
① Le testeur instancie un objet « modèle » ;
② Il le stimule ;③ Il valide directement les données de
cette objet.
Le modèle ne connais pas le contrôleur. Il communique avec ses « clients » le mécanisme de diffusion NSNotificationCenter.
① Le testeur instancie un objet model ; s’abonne, comme le contrôleur, au centre de notification du model ;
② Il stimule directement l’objet modèle ;
③ Il valide alors les notifications reçues.
TDD avec les Vues
Éléments du StoryboardA 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 initialmonViewController * viewController = [storyboard instantiateInitialViewController];
//(ou) pour récupérer un controller par son nommonViewController * viewController = [storyboard instantiateViewControllerWithIdentifier:@"controllerName"];
Tester composants vue
Pour respecter le TDD
①Rédiger le test (composant non « nil »)Définir le « IBOutlet » dans le contrôleur le test est Ko
②Définir le composant dans la vueLe relier avec le « IBOutlet » dans le contrôleur le test est Ok
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:
①XCTAssertEqualObjects([[viewController labelXX] textColor], [UIColor redColor],
@"Bad label color")
②Définir la couleur dans le storyBoard
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, …)
Notre propre mockPour 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•modifier l’attribut directement avec SetValue.
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 à :
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 XcodeClean Code de Robert C. MartinRefactoring Improving The Design of Existing code de Martin Fowler