TDD où l’art de développer à l’endroit

05/12/2017 #AgileTourSophia (par @AgileTourSophia)
Agile Tour Sophia Antipolis
7ème édition – 5 décembre 2017
1
TDD où l’art de développer
à l’endroit
Julien FARGEON

05/12/2017 #AgileTourSophia (par @AgileTourSophia) 2
Merci aux Sponsors !

1.Agilité et Qualité
2.Les tests unitaires
3.TDD – Test Driven Development
4.Quelle approche choisir ?
5.Les styles de TDD
© SOFTEAM Cadextan 2017

1 QUALITÉ ET AGILITÉ
© SOFTEAM Cadextan 2017 4

QUALITÉ ET AGILITÉ
Porter une attention continue à l’excellence technique
9ème principe du
Manifeste Agile

QUALITÉ ET AGILITÉ – POURQUOI ?
Favoriser l’adaptation au changement plus que le suivi d’un plan
4ème valeur du
Manifeste Agile

·
Vu sur le Web…
│ Any fool can write code that a computer can understand. Good programmers write code that Humans can understand. 
Martin Fowler
│ My project is 90 % done. I hope the second half goes as well. 
Scott W. Ambler
│ Codez toujours en pensant que celui maintiendra votre code est un psychopathe qui connait votre adresse. 
Martin Golding

Une application informatique est de qualité lorsque 
le coût d’ajout d’une fonctionnalité reste stable

STRATÉGIE DE TESTS HABITUELLE
Spécification
Réalisation
Tests

·
Les problèmes qui surviennent:
│ « La spécification est mal comprise par les développeurs »
│ « La spécification a été interprétée »
│ « Vous n’avez pas compris ce qu’on voulait! »
│ « Ce n’est pas ce que dit la spécification! »
│ « Aurais-tu un exemple à me donner pour que je comprenne un peu mieux ? »
│ « Les développeurs ne comprennent rien à notre métier »
│ « Le client ne connaît pas l’informatique! »

·
Travailler en collaboration :
│ Des spécifications sont basées sur des exemples:
• Rassurent l’équipe quant à la conformité au besoin
• Réduisent les possibles mauvaises interprétations
• Cassent la barrière d’un langage métier parfois complexe

·
Exemples de spécifications par l’exemple:
│ Calculatrice
• Lorsque je saisis 30, j’appuie sur le bouton ‘+’, je saisis 45, j’appuie sur le bouton égal, alors j’obtiens 75
│ Orthodromie
• La distance orthodromique entre Paris (48°51’N – 2°21’E) et Montpellier (43°36’N – 3°53’E) et de 595 Kms
│ Calcul d’agios
• Sur le 4ème trimestre 2012, un compte est débiteur de 451€ du 13/11 au 28/11 et de 342€ du 08/12 au 27/12, avec un taux d’intérêt de 20%
annuel. Les intérêts sur la période sont de 7,27€

·
Ce qui est essentiel :
·

PILOTAGE PAR LES TESTS
·
Principe :
·
Ces tests vont guider le développement et la conception

APPROCHE AGILE
·
Vision de l’avancement dans un projet traditionnel :
Analyse Design Dev Test
Avancement

APPROCHE AGILE
·
Vision de l’avancement dans un projet Agile :
Avancement
Analyse Design Dev Test
Fct 1
Fct N
…

QUADRANT DE TEST AGILE
Fonctionnels
Exemples
Démos
Acceptation
Prototype
Exploratoires
Utilisateur
Ergonomiques
Alpha/beta
Unitaires
Intégration
Composant
Performance
Sécurité
Rupture
Aideaudéveloppement
Métier
Technique
Aideàlavalidation

QUE FAUT-IL TESTER?
·
Pyramide des tests de Mike Cohn
UI
Intégration
Unitaires

AUTOMATISATION
·
Pourquoi automatiser les tests ?
Feedback 
Permanent

EXTREME PROGRAMMING
http://www.extremeprogramming.org/map/images/loop.gif

POURQUOI AUTOMATISER LES TESTS?
·
Economiquement pertinent
│ Dans la majorité des cas
│ Dépend notamment de la durée de vie de l’application et 
du coût du bug en production
·
Plus fiable qu’un test manuel de l’ensemble du système
·
Pour réaliser des opérations complexes exécutables par une machine
·
Garantir le Feedback du bon fonctionnement de tout ce qui a été développé
·
Radiateur d’information : Améliore l’ambiance et le moral de l’équipe par rapport à ce qui a été accomplis

2 LES TESTS UNITAIRES

DÉFINITIONS
·
Un test unitaire est un test…
│Portant sur une ou partie de l’application testable et la plus petite possible, isolée du reste de
l’application
│Qui détermine si cette partie s’exécute correctement vis-à-vis d’un comportement attendu
·
Partie de code testée = SUT
│SUT : System Under Test
│Peut être une classe ou un petit ensemble de classe (namespace/ package)
·
Un test est avant tout un exemple !
│Exprimé avec des données significatives

EXEMPLE DE TEST UNITAIRE
[TestClass]
class CalculatorTests
{
[TestMethod]
public void shouldAddTwoNumbers()
{
Calculator calculator = new Calculator();
int result = calculator.Add(1,2);
Assert.AreEqual(3, result);
}
}

STRUCTURE D’UN TEST UNITAIRE
·
Structure de base : 3 A
│Arrange
│Act
│Assert
[TestClass]
{
[TestMethod]
{
// Arrange
// Act
// Assert
}
}

STRUCTURE D’UN TEST UNITAIRE
·
Structure issue du BDD
│Given
│When
│Then
[TestClass]
{
[TestMethod]
{
// Given
// When
// Then
}
}

ORGANISATION D’UN TEST UNITAIRE
·
1 méthode par test
·
1 concept testé par test
│= 1 assertion ?
│Ex : Calculator
• 1 test pour la division
• 1 test pour la division par zéro
·
1 classe de test par SUT (System Under Test)
│« Single Responsibility Principle » (S.O.L.I.D)

LIBRAIRIES DE TESTS UNITAIRES
·
Plusieurs librairies en fonction des langages
│ xUnit
• La plus populaire
• Junit, Nunit, CppUnit, etc.
│ Jmockit, Mockito
│ PITest
│ Etc.
·
Déclaration, préparation et nettoyage 
des tests par annotations (ex: Java)
·
Utilisation d’assertions
│ Rendent le test auto-validant
│ Disponibles sous forme de classes et méthodes fournies 
par les frameworks
• assertEquals, assertNull
• assertFalse, assertTrue, fail
• Etc.
@Test
public void test_method_1() {
System.out.println("@Test - test_method_1");
}
// Run once, e.g. Database connection, connection pool
@BeforeClass
public static void runOnceBeforeClass() {
System.out.println("@BeforeClass - runOnceBeforeClass");
}
// Run once, e.g close connection, cleanup
@AfterClass
public static void runOnceAfterClass() {
System.out.println("@AfterClass - runOnceAfterClass");
}
// Should rename to @BeforeTestMethod
// e.g. Creating an similar object and share for all @Test
@Before
public void runBeforeTestMethod() {
System.out.println("@Before - runBeforeTestMethod");
}
// Should rename to @AfterTestMethod
@After
public void runAfterTestMethod() {
System.out.println("@After - runAfterTestMethod");
}

MNÉMOTECHNIQUE
·
F.I.R.S.T.
│Fast
│Independant
│Repeatable
│Self-Validating
│Timely

3 TDD – TEST DRIVEN DEVELOPMENT

DÉFINITION TDD
Test
·
Driven
·
Development
Discipline
de
conception
Conception
émergente
Centré
sur le
besoin
Refactoring
intensif

DÉFINITION TDD
·
Test Driven Development
│La rédaction des tests est la première étape de la formalisation du codage
│Chaque élément de code n’est écrit QUE pour permettre de passer le test
│À chaque modification du code :
• on lance tous les tests écrits par tous les développeurs
• On sait immédiatement si quelque chose ne fonctionne plus
│Les tests sont conservés et maintenus jusqu’à la fin du projet
│Le code est remanié
·
Avantages :
│Interaction entre les cas de tests et la compréhension fine des besoins fonctionnels
│Adhérence du code aux tests
• Intégration forte de la qualité logicielle
│Le code écrit en TDD est plus maintenable, mieux découpé
│Sécurise le développement
Communication !

LE CYCLE TDD
1. Étapes :
1. RED
2. GREEN
3. REFACTOR
http://dbottiau.azurewebsites.net/unit-testing/

PROCESSUS TRADITIONNEL
Spécification
Développement
Tests
Design Non testable
Bugs

TDD
Spécification
Développement
Tests
Design Cycles très courts
FAIL FAST, FAIL SAFE

EN RÉSUMÉ
·
TDD :
│1 discipline de conception de code
│1 cycle : RED – GREEN – REFACTOR
• Approche test F.I.R.S.T.
·
Intérêt du test First :
│Le test est écrit
│Le code testé est testable par nature
• Donc le design est meilleur
│Les assertions sont validées
• Par l’étape RED
│Nécessite de se focaliser sur ce qui est nécessaire
• Evite d’écrire du code inutile
│Chaque test est un pas en avant
│Le debugger est beaucoup moins nécessaire

DESIGN EMERGEANT
·
« First make it work, then make it right »
│Le code fonctionne
│Le code est ensuite refactoré
·
Refactoring
│Elimination de la duplication
│Couplage lâche
·
Les classes et méthodes créées le sont par nécessité
·
Le refactoring est réalisé en permanence
│Chaque opportunité d’améliorer le code est saisie (Scout toujours !)
│Les tests sont là en protection, à tout moment

MNÉMOTECHNIQUE - SIMPLICITÉ
·
Y.A.G.N.I.
│ « You aren’t Gonna Need It ! »
│ Tout ce qui n’est pas absolument utile à un moment donnée n’est pas implémenté
│ Pas d’optimisation prématurée
·
Les décisions sont retardées
│ Eviter de payer le coût de décision prises trop tôt
·
Faire appel aux patterns quand il le faut
│ Inutile d’appliquer des patterns si le besoin n’est pas réel
·
Faire simple ≠ Facile
│ Il est difficile de faire simple

4 QUELLE APPROCHE CHOISIR?

2 APPROCHES TDD
·
Approche Middle-out
│Avantages :
• Permet de se concentrer d’abord sur le domaine
• Séparation des préoccupations plus simples
│Inconvénients :
• Peut conduire à en faire « trop »,  
au-delà de ce qui est nécessaire
UI
Services
Data
Access
Domain

2 APPROCHES TDD
·
Approche Outside-In
│Avantages :
• Tout est guidé par le besoin primaire
│Inconvénients :
• Peut conduire à donner trop de responsabilités 
aux préoccupations de haut niveau
UI
Services
Data
Access
Domain

5 LE TDD C’EST STYLÉ

LES DOUBLURES
Tester une classe qui n’a aucune dépendance est généralement assez simple.
La difficulté va commencer à se faire sentir (et cela devrait arriver presque tout le temps) lorsque les classes
vont utiliser des dépendances.
Nous avons deux solutions pour tester une classe :
1.Tester la classe avec toutes ses dépendances, et si vous comptez faire ça, alors il serait bien que vous sortiez (Nan mais
restez car le plus important c’est de tester le comportement de la classe).
2.Ou bien, nous pouvons essayer d’isoler notre classe de ses dépendances : C’est là où interviennent les tests doubles.

LES DOUBLURES
·
Doublures
│Terme générique qui identifie les objets utilisés en remplacement d’autres objets à des fins de test
│Duplications de classes qui sont plus coopérative que les vrais !!
·
Permettent d’isoler le SUT du reste de système
│Et donc d’écrire de vrais tests unitaires
·
Simplifient l’exécution du test
│Pas besoin d’un environnement spécifique
·
Rendent l’exécution du test plus rapide

LES DUMMIES
·
Inoffensifs
·
Servent de paramètres à une méthode ou à un constructeur
·
Permettent simplement d’appeler correctement la méthode ou le constructeur
·
N’ont pas d’influence sur le code testé
│ Sinon c’est un fake ou un mock
DUMMY N’EST RIEN D’AUTRE QU’UNE CLASSE DONT ON SE FICHE DE
COMMENT ELLE EST UTILISÉE.

LES DUMMIES
interface UserInterface
{
public function getPassword();
public function getUsername();
}
class DummyUser implements UserInterface
{
public function getPassword()
{
return null;
}
public function getUsername()
{
return null;
}
}

LES STUBS
·
Paramétrés pour se comporter d’une certaine façon et retourner certaines valeurs…
http://xunitpatterns.com

LES STUBS
UN STUB EST UNE CLASSE QUI VA RÉPONDRE EXACTEMENT CE QUE J’ATTENDS
class StubUser implements UserInterface
{
{
return 'foo';
}
public function getUsername()
{
return 'Marvin';
}
}
class SendEmail
{
private $user;
public function __construct(UserInterface $user)
{
$this->user = $user;
}
public function forgotPassword()
{
return sprintf(
'Hi %s, your password is %s',
$this->user->getUsername(),
$this->user->getPassword()
);
}
}

LES FAKES
·
Remplace une implémentation existante en rendant son utilisation plus appropriée pour les tests
│ Exemple : base de données
UN FAKE EST UN PEU COMME UN STUB, MAIS AVEC UN PEU DE LOGIQUE,
UNE SORTE DE MINI-IMPLÉMENTATION DE LA VRAIE CLASSE

LES SPIES
·
Un stub qui enregistre des informations lorsqu’il est appelée, ces informations servant lors des assertions
│ Exemple : Serveur de mails
UN SPY VA AVOIR LE MÊME COMPORTEMENT QU’UN STUB, MAIS IL VA NOUS PERMETTRE
D’OBTENIR DES INFORMATIONS SUPPLÉMENTAIRES, UNE FOIS LE TEST EFFECTUÉ.

LES MOCKS
·
Stubs dont on vérifie s’ils se sont comportés comme prévu
IL S’AGIT SIMPLEMENT D’UN OBJET QUI EST UNE SUBSTITUTION COMPLÈTE DE
L’IMPLÉMENTATION ORIGINALE D’UNE CLASSE CONCRÈTE

LES MOCKS
class MockUser implements UserInterface
{
private $numberCalled = 0;
private $numberShouldBeCalled = 0;
{
return 'foo';
}
public function getUserName()
{
$this->numberCalled++;
return 'Marvin';
}
public function setExpectedNumberCalls($number)
{
$this->numberShouldBeCalled = $number;
}
public function verify()
{
if ($this->numberShouldBeCalled != $this->numberCalled) {
throw new Exception(sprintf(
'Actual number of calls %d - expected %d.',
$this->numberCalled,
$this->numberShouldBeCalled
));
}
return true;
}
}
L’UTILITÉ D’UN MOCK :
UNE VÉRIFICATION COMPORTEMENTALE

DES QUESTIONS?

05/12/2017 #AgileTourSophia (par @AgileTourSophia) 57
Merci aux Sponsors !
Julien FARGEON

TDD où l’art de développer à l’endroit

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Similar a TDD où l’art de développer à l’endroit

Similar a TDD où l’art de développer à l’endroit (20)

Más de EspritAgile

Más de EspritAgile (17)

TDD où l’art de développer à l’endroit