Tester c'est douter - Linkvalue tech

#LinkValue #TheGreatPlaceToGeek

Tester c’est douter !

meetup 5 octobre 2016

Test: définition et utilisation

LinkValue #TheGreatPlaceToGeek

Tester, c’est douter ?● Evidemment !

● Tout le monde teste son code

● Test de faisabilité (poc)

● Vérification pendant le développement

● Recette

Test automatisé● C’est un code qui vérifie la validité d’un autre

● C’est un code qui surveille les régressions

● C’est un code dont l'exécution ne nécessite pas l'intervention d'un humain

Pourquoi écrire des tests ?Plus-value à court terme:

● Les tests rassurent

● Ils aident au développement

● Ils permettent certaines vérifications impossibles en manuel

Pourquoi écrire des tests ?Plus-value à moyen terme:

● VSR et VABF plus court

● Facilite l’implémentation de nouvelles fonctionnalités

● Limite voir supprime les régressions

● Facilite la migration et la refactorisation

Pourquoi écrire des tests ?Plus-value à long terme:

● Limite la dette technique

● Accélère la vitesse de développement

● Surveille/ évite le retour des bugs corrigés ● Coût des bugs amoindri

Coût des bugs

Unitaire, Intégration, Fonctionnel

Le test unitaire● Teste unitairement une portion de code

● Assure le bon fonctionnement d’une méthode

● Mock de toutes les dépendances

● Test à granularité fine

● Test de type white box

Le test d’intégration● Teste l’assemblage de plusieurs composants logiciels indépendants

● Ne vérifie pas la conformité des composants

● Assure la cohésion d’un système

● Test à granularité moyenne

● Test de type white box

Le test fonctionnel● Simule l’action d’un utilisateur

● Ne tient pas compte des différentes couches applicatives

● Vérifie le résultat général

● Test à grosse granularité

● Test de type black box

Vue globale

Les tests doubles

Fonctionnement d’un test

● Un test appelle un SUT

● SUT : System Under Test

● Si le SUT possède des dépendances, on les Mocks

● … ou on les Stubs

Définition d’un Stub● Un Stub est centré sur le SUT

● Il lui fournit une indépendance

● Il lui fournit des données utilisées pendant les tests

● Il ne fait jamais échouer le test

● “State-based testing”

Définition d’un Stub● Un Stub est centré sur le SUT

● Il lui fournit une indépendance

● Il lui fournit des données utilisées pendant les tests

● Il ne fait jamais échouer le test

● “State-based testing”

Définition d’un Mock● Un Mock est centré sur le test

● Il décide si le test échoue ou réussit

● Une assertion se fait contre le Mock

● On ne teste pas le résultat mais la manière de l’obtenir

● “Interaction testing”

Définition d’un Mock

Les autres tests doubles

● Dummy : passer en paramètre à l’objet mais n’est jamais appelé

● Fake : l’objet possède une implémentation simple qui retourne toujours le même résultat

● Spy : objet qui surveille le comportement d’un code ne pouvant être relevé

On s’en mock

● Dummy, spies, fake sont des cas spécifiques de mocks ou de stubs

● Comprendre et maitriser l’utilisation des mocks et des stubs induit l’utilisation des autres sans en avoir pleinement conscience

● De toute facon, par abus de language, on appelle tout un “mock”

Bonnes Pratiques

Avant-propos :Tests smellsTest smells définit tout type de test qui ne valide pas la qualité du code

et/ou gène le travail du développeur.

● Test difficile à comprendre et à maintenir.

● Test trop long.

● Test un faux positif ou faux négatif.

● Test avec effet de bord.

● Test multiple comportement en une fois.

● Mock toutes les dépendances

● Seule la classe testée doit être instanciée

● Tester une classe, une méthode et un comportement à la fois

● Si plusieurs comportements par méthode, faire un test pour chacun

Un test unitaire doit être unitaire

Un test unitaire doit être rapide

● Il teste la vitesse d’éxécution du script

● Ne dialogue avec personne (bdd, classe tiers, webservice …)

● Confort pour le développeur (lancer tous les tests avant chaque commit)

Un code doit toujours être testable

● Indicateur de fiabilité

● Indicateur de refactoring

CODEZ PROPRE !!!● Les tests sont le reflet de l’application

● Ils doivent être compréhensibles et maintenables

● Evite le risque de “test smell”

● Non, ce n’est pas qu’un test

● Oui, c’est grave

Testez vos cas d’erreurs

● Faites un test pour chaque cas d’erreur

● Vérifiez la nature de la réponse (boolean, exception … )

● Vérifiez le comportement de vos catch dans le cas d’un try/catch

Une seule méthode par test

● Plus simple à maintenir

● Granularité plus fine en cas de débbugage

Code: Tests:

Nommer proprement vos tests

● Indiquez la méthode testée dans le nom du test : “testMyCustomMethod”

● Indiquez le use case dan le nom du test: “testMyCustomMethodWithSecondParametersMissing”

● Le nom du test doit indiquer son comportement

Identifiez précisement les étapes

● SetUp: équivalent à un construct

● Exercise: déroulement logique du texte

● Verify: contrôle le résultat

● TearDown: équivalent à destruct

Ne laissez pas de traces

● Ajoutez et supprimez les données de test durant les phases de SetUp et TearDown

● Ne vous appuyez pas sur les fixtures

● Toujours remettre votre base de donnée à l’état initiale à la fin de chaque test

Gérez vos données

● Les intéractions avec la base de données doivent être testées lors de tests fonctionnels

● Recréez votre database et vos fixtures avant de lancer vos tests

Vos tests sont des classes comme les autres

● Stockez vos paramètres et dépendances dans des attributs

● Découplez vos méthodes réutilisables (DRY)

● Utilisez les principes SOLID

Ne vous focalisez pas sur le code coverage, mais gardez un ratio de 100% mininum

● 100% ne couvre pas tous les cas de figure

● Moins, c’est la certitude de ne pas couvrir “du tout” une partie du code

● Si moins de 100, alors combien et pourquoi ?

● C’est mettre en péril la valeur qualitative des tests

Aucun test n’est futile● Tester vos Models

● Tester vos getters et setters

● Oui ca sert (principalement en TDD)

● Ca prend cinq minutes à écrire

* attention : aucun test n’est futile! Mais il est inutile de tester le code qui ne vous appartient pas (librairie tierce/framework …)

N’écrivez pas les tests à la fin

● Ecrivez vos tests durant le développement

● Un test est plus simple à écrire quand le code est récent

● Il illustre la mise en pratique du code

● Il complète la doc

● Il limite les “tests smells”

Evitez les valeurs fixes

● Sauf si c’est dans les specs

● Les tests ne doivent pas bloquer l’évolution du code

● Cela provoque un couplage avec le code

Evitez la logique

● Pas de boucle ou de conditions dans un test

● Utilisez les dataProviders pour jouer le test avec plusieurs valeurs

● Simplifiez la compréhension de vos tests

Mauvaises idées

● Modifier les paramètres d’environnement pour faire passer certains tests

● Certains tests ne fonctionnent pas partout

● Mon test unitaire est long car …

● Certains tests sont aléatoirement en échec

Cas pratique

Mise en situationContexte:

1. On récupère depuis un api externe des données utilisateurs

2. On enregistre les données en base via un orm

3. On retourne une réponse

Les différents tests

Rouge : Les tests unitaires

Orange : les tests d’intégrations

Vert : les tests fonctionnels

Ecrire un Test unitaire● Déclarez les mocks

des dépendances de la classe testée en attribut de la classe de test.

● Idem pour la config

Ecrire un Test unitaire● Dans l’exercise,

définissez le comportement de votre test

● Dans le verify assurez vous de la réponse attendue. Un test doit contenir au moins une assertion

Ecrire un Test unitaire● Testez les appels des

méthodes de vos mocks ainsi que le nombre d’appels

● Testez également les paramètres passés en argument

● Surveillez toutes les étapes d’avancement de votre code

Ecrire un Test unitaire● Ne tester que des comportements attendus: inutile de s’assurer qu’une

méthode non utilisée n’est pas appelée

● N’utilisez pas les dataProviders pour tester plusieurs fois le même cas de figure.

● Faites toujours attention de tester le comportement attendu de votre code et non le code écrit

Ecrire un Test d’intégration● On ne teste pas le bon

fonctionnement des différentes couches, on teste leurs intéractions

● On mock les dépendances externes (webservice, BDD …) qui pourrait faire échouer les tests alors que le code est bon

● On ne vérifie pas le résultat des dépendances, on vérifie la réponse de la méthode testée

Ecrire un Test d’intégration

● Utilisez intelligemment les mocks, mais pas trop

● Dans cet exemple l’objet User ne devrait pas être mocké

● Ne mockez que les classes qui comportent des dépendances externes

Ecrire un Test d’intégration

● Un test d’intégration intervient dès lors qu’on teste plusieurs classes

● Il ne remplace pas un test unitaire, il le complète

● Les tests d’intégrations sont souvent plus lents et plus fragiles que les tests unitaires

Ecrire un test fonctionnel● Ne vous appuyez pas sur les

données de fixtures

● Utilisez des transactions pour vos appels en bdd

● Configurer le lancement de la transaction dans le setUp et son rollback dans le tearDown

Ecrire un test fonctionnel● Ne vous occupez pas du code

● Testez uniquement le résultat

● Testez une valeur fixe seulement si elle est unique

● Ne testez qu’un seul comportement par test

Ecrire un test fonctionnelLes tests fonctionnels doivent être lancés sur un serveur applicatif dédié et iso prod.

Pour les dépendances externes (API) : ● Si une version de test existe, configurez et appelez l’api de test● Si vous appelez une api de prod, connaissez les données retournées

Pour la base de données: ● Appelez une base de données de test● Utilisez des fixtures pour remplir la base de donnée

Test Driven Developement

Késako ?

● TDD : Acronyme de Test Driven Development

● Développement piloté par les tests

● Ecrire le test avant le code

Process TDD1. On écrit le test

2. On vérifie que le test échoue

3. On écrit le code le plus vite possible

4. On vérifie que tous les tests soient verts

5. On refactorise le code proprement

Pourquoi travailler en TDD

● Structure le code avant écriture

● Participe intégralement au process de développement

● Evite l’écriture de tests qui valident le code existant

Difficultés● Simple à comprendre, moins à utiliser

● Nécessite de la pratique

● Force à réapprendre une logique de développement

● Chercher le rouge, ne jamais le commiter

La Team DD

Problèmatique TDD

● Ca sert à quoi d’écrire les tests en premiers ?

● Je dois tout tester ou seulement certaines choses ?

● Que dois-je tester en premier ?

BDD à la rescousse

● TDD : Incite le développeur à se poser les bonnes questions

● BDD : Behaviour Driven Development.Aide les différents corps de métiers à se poser les bonnes questions ensemble

Scénariser les tests● Les tests ne sont plus écrits par les développeurs à partir du cahier

des charges

● Client et développeurs décident ensemble des tests à écrire

● Ecriture de scénario décrivant le comportement de l’application et donc le comportement à tester

● Utilisation d’un langage commun entre le client et le développeur : le gherkin

Comment tu me causes ?

● Utilisation d’un “ubiquitous language” gherkin

● Compréhensible par l’ensemble des métiers

● Utilise la matrice Given/When/Then pour écriture de scénario

Ecrire un scénario● Votre scénario décrit le

comportement attendu

● Given pose le contexte

● When indique le déroulement de l’action

● Then le résultat attendu

Coder un scénario● Le code reprend les étapes

setUp / exercise / Verify

● BDD permet de coder des tests fonctionnels

● Ces tests fonctionnels serviront alors de scénario pour les tests unitaires

BDD + TDD1. (story) Pour chaque scénario décrivant la fonctionnalité

2. (RED) Lancer le scénario qui va échouer

3. (RED) Définir la première étape

4. (GREEN) Ecrire le code de l’étape pour la faire passer

5. (REFACTOR) Refactorer le code et répéter les étapes 4&5 pour chaque étape jusqu’à ...

6. (GREEN) Le scénario passe

7. (REFACTOR) Refactorer le code de l’application

BDD + TDD

● L’écriture des tests est dirigée par les scénarios

● BDD n’est pas un remplacant de TDD

● Concept de développement Agile

BDD + TDD + DDD

Pour Conclure● Tester c’est inutile : Seuls les mauvais développeurs ne doutent pas

de leur code

● C’est trop difficile : Non, mais cela demande de l’investissement. Les bonnes pratiques et les patterns de tests aident pour démarrer

● C’est irréaliste : Regardez autour de vous ! Sur github tout type de projet et de toute taille les utilisent et fonctionnent. C’est plus régulier de trouver un projet couvert par les tests

● C’est pas mon job : As tu déjà réfléchis à une reconversion ? Les tests c’est du code

Questions ?

Sources:

● http://www.thedarksideofthewebblog.com/les-mocks-sont-ils-nos-amis/

● http://blog.viseo-bt.com/tests-unitaires-dintegration-fonctionnel-metier-comment-les-definir/

● http://blog.xebia.fr/2008/04/11/les-10-commandements-des-tests-unitaires/

● http://blog.soat.fr/2013/09/10-trucs-infaillibles-pour-rater-ses-tests-unitaires-en-toutes-circonstances-12/

● http://agilitateur.azeau.com/post/2010/09/05/Stub-et-Mock-montent-sur-sc%C3%A8ne

● http://agilitateur.azeau.com/post/2011/04/12/Pour-en-finir-avec-les-Stubs-et-les-Mocks

● http://xunitpatterns.com/

● http://xunitpatterns.com/Test%20Stub.html

● http://fr.slideshare.net/ohoareau/intro-sur-les-tests-unitaires

Tester c'est douter - Linkvalue tech

Technology

Transcript of Tester c'est douter - Linkvalue tech

Pix & Tech Nîmes

Tech & Bio

PASS FRENCH TECH · MÉTROPOLE FRENCH TECH Bordeaux Métropole Numérique IMPLANTATIONS France, Royaume-Uni, Allemagne, Espagne, Russie, Singapour PASS FRENCH TECH …

Tech trends 2013

Tester vos services_paris_web_2011

Deloitte2014 tech trends

Renforcez votre force commerciale avec Euridis...Euridis Business School high-tech high-tech high-tech high-tech high-tech high-tech high-tech EURIDIS EN QUELQUES MOTS • Leader de

VOUDRIEZ-VOUS TESTER NOS - Belgocycle

Web viewTECH-1Formulaire de Soumission de la Proposition Technique. TECH-2Capacité Financière du Consultant. TECH-3Structure du Consultant. TECH-4Expérience du

Tech Guide

CENTRIFUGEUSES - Cereal Tester

Tester la persistance Java avec Arquillian

Methodologie, mesurer, tester,hypotheses

Tester les applications Zend Framework

Comment bien tester son site RWD ?

Methodologie Mesurer Tester Des Hypotheses

IntelliSciences & Tech - Universcience

Afrique & tech SOMMAIRE

VRAC TECH Bilan du salon TECH TRADE SHOW SEPEM Industries ... · VRAC TECH BULK TECH TRADE SHOW by SEPEM Industries Bilan du salon VRACTECH / Trade show VRACTECH wrap up ... Too bad

Market review Tech