feat(converter): add converter for all tests cucumber

[MayuriXx]

Guide : Utilisation de @DataTableType dans les tests Cucumber

Principe

@DataTableType est une annotation Cucumber qui convertit automatiquement les lignes d'une DataTable (fichier .feature) en objets Java typés. Plus besoin de parser manuellement les DataTable dans les steps.

---

Comment ça marche

.feature (données brutes)  →  @DataTableType (conversion)  →  Step (objet typé)

1. Cucumber lit la DataTable dans le .feature
2. Il cherche un @DataTableType dont le type de retour correspond au type attendu par le step
3. Il applique le converter à chaque ligne et injecte le résultat dans le step

---

Mise en place

1. Créer une classe de converters

Placer un fichier dans le même package que les steps (ex : feature/). Cucumber le détecte automatiquement.

package feature;

import io.cucumber.java.DataTableType;
import java.util.List;
import java.util.Map;

public class CucumberTypeConfig {
    // Les converters vont ici
}

2. Choisir le bon type de converter selon le format de la DataTable

Format A — Table sans en-tête (liste de paires)

And the user profile
  | id        | <generated_id> |
  | firstname | Emma           |

Chaque ligne arrive comme une List<String> :

public record FieldAssertion(String field, String expected) {}

@DataTableType
public FieldAssertion fieldAssertion(List<String> row) {
    return new FieldAssertion(row.get(0).trim(), row.get(1).trim());
}

Le step reçoit une List<FieldAssertion> :

@And("the user profile")
public void theUserProfile(List<FieldAssertion> assertions) {
    // assertions = [FieldAssertion("id", "<generated_id>"), FieldAssertion("firstname", "Emma")]
}

Format B — Table avec en-têtes (une ou plusieurs lignes d'objets)

Given the following users
  | gender | firstname | lastname | email              |
  | female | Emma      | Stone    | emma@example.com   |
  | male   | John      | Doe      | john@example.com   |

Chaque ligne arrive comme un Map<String, String> (clé = en-tête) :

@DataTableType
public UserRequest userRequest(Map<String, String> row) {
    return new UserRequest(
        row.get("gender"),
        row.get("firstname"),
        row.get("lastname"),
        row.get("email")
    );
}

Le step reçoit une List<UserRequest> :

@Given("the following users")
public void theFollowingUsers(List<UserRequest> users) {
    // users = [UserRequest("female", "Emma", ...), UserRequest("male", "John", ...)]
}

Format C — Table à une seule ligne (objet unique)

Même DataTable avec en-têtes, mais le step attend un seul objet :

@Given("a user")
public void aUser(UserRequest user) {
    // Cucumber applique le même @DataTableType et prend la 1ère ligne
}

---

Récapitulatif des signatures

Format DataTable	Paramètre du @DataTableType	Type dans le step
Sans en-tête, 2 colonnes	List<String> row	List<MonRecord>
Avec en-têtes	Map<String, String> row	List<MonRecord> ou MonRecord
Cellule unique	String cell	List<MonType>

---

Bonnes pratiques

• Un fichier dédié (CucumberTypeConfig.java) pour centraliser tous les converters
• Utiliser des records pour les types convertis (immutables, concis)
• Même package que les steps — Cucumber scanne le package automatiquement
• Nommer le converter comme le type retourné (convention, pas obligation)
• Ne pas mélanger logique d'assertion et conversion — le converter ne fait que transformer

---

Bonus : @ParameterType

Pour les paramètres inline (pas les DataTables) :

When the client call to GET /random-users/42

@ParameterType("\\d+")
public Long userId(String id) {
    return Long.parseLong(id);
}

@When("the client call to GET \\/random-users\\/{userId}")
public void getUser(Long id) { ... }

{userId} dans l'expression fait le lien avec le nom de la méthode userId().

[Copilot]

Pull request overview

This PR updates the Cucumber test suite to use typed Cucumber converters (DataTable and parameter types) and adapts existing steps/scenarios to the new typed bindings.

Changes:

• Introduces CucumberTypeConfig with @DataTableType and @ParameterType converters.
• Refactors StepDefinition.theUserProfile to consume a typed List<FieldAssertion> instead of DataTable.
• Updates the “non-existent user” GET scenario to use a different hardcoded ID and switches the GET step to {userId}.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/test/resources/features/get_user.feature	Updates the non-existent user ID used in the GET scenario.
src/test/java/feature/StepDefinition.java	Uses typed DataTable conversion for profile assertions and a custom {userId} parameter type for GET.
src/test/java/feature/CucumberTypeConfig.java	Adds Cucumber DataTable and parameter converters (FieldAssertion, UserRequest, userId).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sonarqube-xpeho]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[Theo-lbg]

LGTM

[profotoce59]

C'est clairement beaucoup plus propre pour moi