CocoaHeads Toulouse - Xcode et les tests - Epitez

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