Peut-on tester un module de prise de rendez-vous médical sans jamais toucher à une vraie donnée de patient ? La question se pose dès la première ligne de code sur ce type de projet, et la réponse tient en un principe simple : toutes les fixtures doivent être générées, jamais extraites.
Sur un module WordPress destiné à un centre de santé ou une clinique, la tentation est grande de récupérer un export anonymisé de la base de production pour disposer de jeux de données réalistes. C’est précisément l’erreur à éviter : même pseudonymisé, un export réel peut recéler des informations sensibles, et son usage en environnement de test pose un problème de conformité en soi. Ce billet ne traite pas de l’anonymisation des journaux de production, qui relève d’une problématique distincte.
Pourquoi un export réel, même filtré, reste un risque
Un export « anonymisé » à la main oublie presque toujours un champ : un commentaire libre du praticien, un numéro de téléphone resté dans un champ texte, une adresse email de contact d’urgence. Le seul moyen d’être certain qu’aucune donnée patient ne circule dans l’environnement de test est de ne jamais partir d’une donnée réelle.
La stratégie retenue consiste à construire un générateur de fixtures entièrement fictif, avec des noms, des dates de naissance et des motifs de consultation inventés, mais suffisamment variés pour couvrir les cas réels du métier.
Construire une factory de patients fictifs
La factory PHPUnit du cœur de WordPress permet de créer ces enregistrements directement en base de test, sans jamais lire de fichier externe.
class Patient_Factory extends WP_UnitTest_Factory_For_Post {
public function create_object( $args ) {
$args = wp_parse_args( $args, array(
'post_type' => 'patient',
'meta_input' => array(
'nom_complet' => 'Patient Test ' . wp_rand( 1000, 9999 ),
'date_naissance' => '1980-01-01',
'motif' => 'consultation de suivi',
),
) );
return parent::create_object( $args );
}
}Le suffixe aléatoire dans le nom garantit qu’aucune collision n’apparaît si plusieurs tests créent des patients en parallèle, un détail qui évite bien des faux positifs difficiles à diagnostiquer.
Couvrir les cas métier sans données réelles
Un module de rendez-vous médical doit gérer des situations précises : un créneau déjà pris, un praticien en congé, un rendez-vous de suivi qui doit respecter un délai minimal après la dernière consultation. Chacune de ces règles se teste avec des fixtures pensées pour l’occasion, pas avec un échantillon de vrais patients.
- Un patient avec plusieurs rendez-vous passés, pour tester le calcul du délai de suivi
- Un praticien avec un agenda complet, pour tester le refus de double réservation
- Un rendez-vous annulé la veille, pour tester la libération du créneau
Générer des motifs de consultation variés
Pour éviter qu’un test ne masque un bug en utilisant toujours le même motif, on pioche aléatoirement dans une liste de motifs fictifs prédéfinis dans la factory, jamais copiée depuis une vraie base de patients.
Tester le calcul des créneaux disponibles
Le cœur du module repose souvent sur une fonction qui calcule les créneaux libres à partir de l’agenda du praticien et de la durée standard d’une consultation.
public function test_creneau_pris_nest_plus_propose() {
$praticien_id = $this->factory->post->create( array( 'post_type' => 'praticien' ) );
$this->factory->post->create( array(
'post_type' => 'rendez_vous',
'meta_input' => array(
'praticien_id' => $praticien_id,
'creneau' => '2020-09-10 10:00',
),
) );
$creneaux = Agenda::creneaux_disponibles( $praticien_id, '2020-09-10' );
$this->assertNotContains( '10:00', $creneaux );
}Ce test isole un cas précis, la non-disponibilité d’un créneau déjà réservé, sans jamais avoir besoin d’un vrai identifiant patient issu de production.
Documenter la politique de fixtures pour toute l’équipe
Sur ce type de projet, une règle écrite noir sur blanc dans le dépôt évite bien des malentendus, y compris avec un développeur qui rejoint l’équipe en cours de route.
- Interdiction formelle d’importer un export de base réelle en environnement de test
- Toutes les fixtures passent par une factory versionnée et documentée
- Revue de code obligatoire sur tout nouveau jeu de données de test
La règle qu’on applique sur ces projets tient en une phrase : si une donnée de test ressemble trop à une vraie personne, elle est probablement mal choisie.
En résumé
Sur un module de santé, la qualité des tests ne doit jamais se payer au prix de la confidentialité des patients. Une factory de fixtures entièrement fictive, combinée à des scénarios pensés pour couvrir les règles métier réelles, permet d’obtenir une couverture solide sans jamais approcher une donnée sensible.
