Skip to content

Analyse des tests déjà fournis (back-end)

Lecture des deux classes de test fournies par le starter code, en reviewer, avant d'écrire quoi que ce soit.

UserServiceTest.java (tests unitaires, Mockito)

  • @ExtendWith(SpringExtension.class), mais aucun contexte Spring n'est chargé : les dépendances (UserRepository, PasswordEncoder) sont de purs mocks Mockito (@Mock), injectées dans UserService via @InjectMocks. Rapide (~1s), pas de base de données.
  • Convention de nommage : test_<action>_<condition>_<résultat attendu>.
  • Structure GIVEN / WHEN / THEN en commentaires dans chaque test.
  • 3 cas déjà couverts sur register() :
  • user null → IllegalArgumentException.
  • login déjà existant en base → IllegalArgumentException.
  • cas nominal → userRepository.save() appelé avec le bon objet (vérifié via ArgumentCaptor).
  • login() n'est testé nulle part — ni le cas nominal (token généré), ni mot de passe invalide, ni utilisateur inconnu.

UserControllerTest.java (tests d'intégration, Testcontainers)

  • @SpringBootTest(webEnvironment = RANDOM_PORT) + @AutoConfigureMockMvc
  • @Testcontainers : démarre le contexte Spring complet (sécurité, JPA, controllers réels) contre un vrai conteneur MySQL (mysql:8.0, voir étape 2 de l'Exercice 1 pour le détail du fix Testcontainers/Docker Desktop).
  • @DynamicPropertySource : reconfigure spring.datasource.* pour pointer vers le conteneur de test, et force spring.jpa.hibernate.ddl-auto=create (schéma recréé à chaque run, isolation totale entre exécutions).
  • @AfterEach : userRepository.deleteAll() — la base est vidée entre chaque test (pas de dépendance d'ordre entre tests).
  • Appels HTTP réels via MockMvc (mockMvc.perform(post(...))), assertions sur le status code (MockMvcResultMatchers.status()), .andDo(print()) pour le débogage.
  • 3 cas déjà couverts sur POST /api/register :
  • corps de requête vide → 400.
  • login déjà existant → 400.
  • cas nominal → 201.
  • POST /api/login n'est testé nulle part.
  • /api/students (Exercice 1, étape 4) n'a aucun test.

Constat

Les deux classes couvrent bien register(), mais rien sur l'authentification (login, génération/validation JWT) ni sur le CRUD étudiants ajoutés en Exercice 1. C'est le point de départ du plan de tests (étape 2) : compléter les classes existantes en suivant les mêmes conventions, puis en créer de nouvelles pour JwtService et Student*.