CocoaHeads Toulouse - Xcode et les tests - Epitez

XCode & Les Tests
ou
Des Tests au Code
Ekito - Cocoahead
Epitez - JF Marronnier

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

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
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

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
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è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.

É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"];

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

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

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 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

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 Xcode
Clean Code de Robert C. Martin
Refactoring Improving The Design of Existing code
de Martin Fowler

CocoaHeads Toulouse - Xcode et les tests - Epitez

Contenu connexe

Tendances (20)

En vedette (20)

Similaire à CocoaHeads Toulouse - Xcode et les tests - Epitez (20)

Plus de CocoaHeads France (20)

CocoaHeads Toulouse - Xcode et les tests - Epitez