Tests Logiciel

Les testsPourquoi? Comment?

Nathaniel Richand

02/2009

© British Telecommunications plc

Sommaire

• Introduction aux tests

• Présentation du Test Driven Development

• Conclusion

• Votre avis


Introduction aux tests


Il n’y a pas de soucis à livrer du code qui ne fonctionne pas. Quelle est la conséquence ?

Enjeux financiers faibles

Perte de confort

Enjeux financiers

importants

Enjeux humains


De quoi parle-t-on?

• Différents types de test :

IHM

Acceptation

Intégration

Unitaire

IHM

Acceptation

Intégration

Unitaire

Boite blanche

Boite noire

Tests de l’interface graphique. Identiques à ceux réalisés par la MOA.

Tests fonctionnels exécutés avant une livraison (qualification).

Valide le fait que toutes les parties développées indépendamment fonctionnent bien ensemble.

Teste une partie donnée, indépendamment du reste du programme.


Pourquoi fait-on si peu de tests?

Pas le temps

Pas un besoin « métier »

Outils pas au point

Seuls les test d’IHM sont plus délicats

Plus les corrections arrivent tard

Plus c’est cher

No comment…


A quoi servent les tests?

• Assurer la qualité :– L’application fonctionne– L’application fait ce qui est attendu– L’application a de bonne performance– …

• Mais pas que ça :– Assurer la non régression– Améliorer la productivité– Permettre le refactoring– Permettre de comprendre le code

(les tests explicitent le code)


Manque de temps : faux problème ?

Les bugs doivent être corrigés (en général…)

Mieux vaut le faire le plus tôt possible.

Expression des besoins

Analyse

& designDEV

Tests

PROD

Temps

Coût du changement


Technical debtNous n’avons pas le

temps de faire des tests ou de refactorer le code

Temps

Cap

acité

à p

rodu

ire

Max

Actuelle

Plus le temps passe, plus Plus le temps passe, plus les erreurs commises se les erreurs commises se

font ressentir.font ressentir.

Code dupliqué

Faiblementtesté

Code dégradé, difficile

Extrait de : Henrik Kniberg – 10 ways to screw up with Scrum and XP

La dette technique fait diminuer La dette technique fait diminuer la productivité au fil du temps.la productivité au fil du temps.


Technical debt (2)

Temps

Cap

acité

à p

rodu

ire

TempsC

apac

ité à

pro

duire

Max

Actuelle

Max

Actuelle

Produire du code de meilleur qualité et testé à un coût plus élevé uniquement sur le court terme.

"Ceux qui s'avancent trop précipitamment reculeront encore plus vite."

Meng-Tseu


Pyramide de Mike Cohn

IHM

Acceptation

Intégration

Unitaire

Approche traditionelle Approche « agile »

Basée sur des cahiers de recettes.Coût d’entrée faible.Coût de maintenance très élévé.

Basée sur des outils d’automatisation.Coût d’entrée plus élevé.Coût de maintenance assez faible.


LE TDD


Test Driven Development?

Ajouter un test

Vérifier que le test échoue

Ecrire le codeVérifier que le

test passe

Refactor

RED

GREEN

REFACTOR


On commence par une architecture la plus simple

possible, puis on la fait évoluer suivant les besoins.

On ne code que ce qui correspond à un besoin

bien identifié, que l’on sait tester

Philosophie du TDD

Programmation parintention

Notion de design émergent

KISS Keep It Simple, Stupid


TDD : Démonstration

Client

Panier

coutTotal : int

ajouterProduit()

enleverProduit()

majCoutTotal()

Produit

nom : String

cout : int


Conclusion


Comment se lancer

• Java :– Junit !– Dbunit pour les BDD– EasyMock– Unitils

• .Net :– Nunit ou MS Test – Rhino Mocks

• IHM web :– Selenium


C’est pas mon boulot?


Les problèmes qui surviennent

• Tests trop longs à exécuterUtiliser un serveur d’intégration continu

• Maintenabilité des tests– Les tests doivent évoluer en parallèle du code

Ne pas faire de tests inutiles

• Manque d’engagement de l’équipe– Si l’équipe ne vérifie pas le passage des tests, ne fait pas

évoluer les tests, alors l’intérêt est faible…

• Code trop difficile à testerBesoin bien compris ?Utiliser l’injection de dépendance, des mocks ?


Mon parti pris (qui n’engage que moi)

• Coder avec des tests est bien plus agréable et bien plus facile.

• Ne pas faire trop de tests non plus.– Se concentrer sur les parties «métier» en unitaire– Faire des tests fonctionnels de l’application.

• Avec habitude les tests deviennent très rapide à produire.

• Je fais beaucoup moins de bugs (j’ai l’impression!).

Dépend du

contexte


Votre avis?


Ressources

• Généralité sur les test :http://www.testdriven.com

• TDD :Test Driven: TDD and Acceptance TDD for Java Developers - Lasse Koskela

• Guides de bonnes pratiques de tests en java :http://unitils.org/guidelines.html

• Outils .net :http://www.artofunittesting.com/Chapters/Tools_and_frameworks

Technology

Tests Logiciel