Talk de Juliette de Rancourt de CarbonIT et Julien Topçu @julienTopcu de la SG.

Abstract

Saviez-vous que JUnit 5 a déjà plus d’un an ? Pourtant, un grand nombre de projets Java sont encore testés avec JUnit 4, qui est sorti… il y a 13 ans ! Enormément de choses ont évolué depuis 2006, Java a pris 6 versions ! Ne serait-il donc pas temps de remettre nos tests au goût du jour ? L’équipe JUnit a profité de cette 5ème version pour restructurer complètement le framework. De nombreuses features ont été ajoutées ou retravaillées afin de s’adapter aux nouveaux paradigmes de l’écosystème Java. Lors de ce talk, nous verrons que même si tout cela a introduit beaucoup de changements, les mécanismes de rétro et post compatibilité garantissent une migration facile et progressive.

Notes

Repo Git du code : https://gitlab.com/crafts-records/remember-me

On a splitter le unit en 3 modules

• junit vintage (retro comptabilité avec unit 4)
• Importer une 2eme dépendance junit.jupiter
• Importer punit plateform pour l’intégration des outils Up- grade maven-surefie-plugin

Modification des annotations

• @BeforeClass —> @BeforeAll
• @Before -> @BeforeEach
• @Ignore -> @Disabled

Modification des classes

• Assert —> Assertions
• La classe Test change de package
• On n’a plus besoin de renseigner public

Junit 5

• nouvelle assertion pour les exception et ne plus passer pas les @Rule
• AssertAll : Fait le check de toutes les assertions en meme temps
• Paramètres test :
  • Rajouter un paramètre de mon test
  • Rajouter @ParametredTest
    • On peut le nommer avec un attribut name de l’annotation
  • @ValueSource pour les valeurs
  • @NullSource @NullAndEmptySource
  • Si plusieurs paramètres : @CsvSource avec les paramètre en string spéparé par des « , ». Par exemple : «p1,p2 »
• @MethodSource permet d’appeler une méthode qui crée les tests
• @Nestd : pour faire une Nested Test class
• @ExtendWith(SptringExtension.class) pour interfacer avec Spring
• @DisplayName : Override ne nom par défaut
• @DisplayNameGeneration (Replace underscore)
• On peut avec @ParameterResolver
• On peut aussi implémenter l’extension & mettre bq d’extension
  • Permet de séparer l’endroit ou on crée les objets de tests & les tests
• On peut remplacer le resolver par un @Inject
• On peut tester les equals & hashcode à partir des interfaces
• On peut faire des tests d’interface