Guillaume Ehret présente des règles pour améliorer la qualité des tests unitaires, soulignant l'importance de la clarté, de l'isolation et de l'automatisation. Il propose dix principes, tels que la granularité des tests, l'utilisation de assertions claires, et la nécessité d'exécuter les tests fréquemment. Un accent est mis sur l'utilisation d'outils de mock et de frameworks comme Mockito et AssertJ pour optimiser le processus de test.

1. Tests unitaires
simplifier les Assertions
by Guillaume EHRET

2. Guillaume EHRET
Développeur agile depuis 12 ans
passé par la case gestion de projet et aujourd'hui architecte applicatif pour
le compte des laboratoires Boiron
Pour me suivre
@guillaumeehret
http://gplus.to/guillaumeehret

3. Mon blog http://javamind-fr.blogspot.fr/

4. Pourquoi ce lightning talk ?
Tout développeur connait le principe des tests
unitaires et devrait les utiliser

5. Les TU ne sont pas qu'une question
de couleurs

6. ni qu'une question de % de
couverture du code par les tests
>80% < 40%

7. La qualité des tests est aussi
importante que la qualité du code

8. 10 règles pour améliorer la qualité
de vos tests unitaires

9. Améliorer la qualité de vos tests
en 10 règles
1. Principe de la boite noire
un unit doit être considéré comme une boite noire à laquelle on passe
des paramètres d'entrée et qui va soit nous renvoyer un résultat
directement soit agir sur un système distant
2. Granularité
- si une méthode et plusieurs comportements ==> plusieurs tests
- si un comportement via plusieurs méthodes ==> un seul test
3. Consistence dans le temps
attention aux tests liés dates, aux appels asynchrones, services distant...

10. Améliorer la qualité de vos tests
en 10 règles
4. Avoir des tests lisibles
- la classe de test doit avoir un nom clair. Si elle est liée à une classe on
applique le pattern NomClasseTest
- le nom de la méthode doit tout de suite indiquer vos intentions. Utilisez
le should. Par exemple getById_ShouldReturn_AnEntity ou
getById_ShouldNotReturn_AnEntity_IfIdNull
- Forcez vous à utiliser autant voir plus de commentaires dans vos tests
que dans votre code
5. Utiliser des assertions claires
- utiliser un framework tel que FestAssert ou AssertJ (fork de fest assert)
- vous pouvez utiliser plusieurs assert dans une méthode de tests mais
toujours liés à la vérification du même comportement sinon découper vos
tests en plusieurs méthodes

11. Améliorer la qualité de vos tests
en 10 règles
6. Isolation entre les tests
- l'ordre d'exécution ne doit pas influer sur le résultat
- remettre le système dans le même état qu'avant l'exécution du test
- le setup global d'un test ne doit contenir que des initialisations
communes à tous les tests
7. Isolation entre les composants
Utiliser des mocks au maximum pour toutes les interactions externes
Le framework Mockito est très simple d'utilisation
8. Temps d'exécution
les tests doivent être joués le plus souvent possible
exécuter les tests complets sur un serveur d'intégration continue tel que
Jenkins

12. Améliorer la qualité de vos tests
en 10 règles
9. Automatiser l'exécution des tests
- automatiser l'exécution des différents scénarios de tests et ne pas
arrêter l'exécution automatique de ces tests une fois que l'application est
en production
- Séparer les tests unitaires, d'intégration ou fonctionnels dans le process
de build
10. Pas de catch exception
utiliser le @Test(expected = MyException.class)
si vous tester des cas passant et que votre code retourne des checked
exception rajoutez un throws pour les remonter plus haut

13. Rendre plus lisible ses assertions
JUnit
assertEquals(expected, actual);
confirme que égal à expected est l'objet actual?
Hamcrest
assertThat(actual, equalTo(expected));
confirme que l'objet actual est égal à expected ?
FEST-Assert / AssertJ
assertThat(actual).isEqualTo(expected);
confirme que l'objet actual est égal à expected ?

14. Références
http://infinitest.github.io/
https://github.com/junit-team/junit/wiki
http://hamcrest.org/
http://fest.easytesting.org/
https://github.com/joel-costigliola/assertj-core
http://martinfowler.com/articles/nonDeterminism.html
https://code.google.com/p/mockito/