Tests unitairessimplifier les Assertions

by Guillaume EHRET

Guillaume EHRET

Développeur agile depuis 12 anspassé par la case gestion de projet et aujourd'hui architecte applicatif pour le compte des laboratoires Boiron

Pour me suivre@guillaumeehrethttp://gplus.to/guillaumeehret

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

Pourquoi ce lightning talk ?

Tout développeur connait le principe des tests unitaires et devrait les utiliser

Les TU ne sont pas qu'une question de couleurs

ni qu'une question de % de couverture du code par les tests

>80% < 40%

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

10 règles pour améliorer la qualité

de vos tests unitaires

Améliorer la qualité de vos testsen 10 règles

1. Principe de la boite noireun 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 tempsattention aux tests liés dates, aux appels asynchrones, services distant...

Améliorer la qualité de vos testsen 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

Améliorer la qualité de vos testsen 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 composantsUtiliser des mocks au maximum pour toutes les interactions externesLe framework Mockito est très simple d'utilisation

8. Temps d'exécutionles tests doivent être joués le plus souvent possibleexécuter les tests complets sur un serveur d'intégration continue tel que Jenkins

Améliorer la qualité de vos testsen 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 exceptionutiliser 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

Rendre plus lisible ses assertions

JUnit assertEquals(expected, actual);confirme que égal à expected est l'objet actual?

HamcrestassertThat(actual, equalTo(expected));confirme que l'objet actual est égal à expected ?

FEST-Assert / AssertJassertThat(actual).isEqualTo(expected);confirme que l'objet actual est égal à expected ?

Références

http://infinitest.github.io/https://github.com/junit-team/junit/wikihttp://hamcrest.org/http://fest.easytesting.org/ https://github.com/joel-costigliola/assertj-corehttp://martinfowler.com/articles/nonDeterminism.htmlhttps://code.google.com/p/mockito/