# Tester une extension e-learning contre trois versions majeures de LearnDash

> Une matrice de tests qui rejoue la même suite d'intégration contre trois versions de LearnDash pour sécuriser chaque montée de version côté client.

- Auteur : WordPress Développement
- Publié le : 2022-03-09
- Mis à jour le : 2022-03-09
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/tester-extension-e-learning-versions-learndash/

## L’essentiel

- Matrice CI à trois versions, une image par branche
- Fixtures de cours isolées par test
- Rapport de compatibilité généré automatiquement

Combien de versions d'une extension tierce faut-il couvrir avant de dormir tranquille ? Pour un plugin qui pilote le suivi de progression sur LearnDash, la réponse tenait en un chiffre : trois. La version installée chez le client le plus ancien, celle recommandée en ce moment, et la bêta publique que l'éditeur pousse sur son canal de test. En dessous, une régression silencieuse passe inaperçue pendant des semaines.

Le problème classique avec les extensions e-learning, c'est que leurs API évoluent par petites touches : un filtre renommé, un statut de cours qui change de valeur, une fonction dépréciée sans avertissement bruyant. PHPUnit seul ne suffit pas à couvrir ce risque ; il faut un dispositif qui exécute la même suite contre plusieurs cibles.

## Poser le périmètre du test

L'objectif n'était pas de tester LearnDash lui-même, mais l'intégration : la façon dont le plugin lit la progression d'un apprenant via `learndash_course_progress()` et déclenche ses propres actions personnalisées. Un test qui casse doit pointer vers une incompatibilité d'API, jamais vers un bug interne à LearnDash.

Trois scénarios ont été retenus : validation d'une leçon, franchissement d'un quiz avec note minimale, et clôture de cours avec génération de certificat. Ce sont les points où le plugin lit ou écrit des données appartenant à LearnDash.

## Construire la matrice dans la CI

> L'essentiel à retenir : Matrice CI à trois versions, une image par branche ; Fixtures de cours isolées par test ; Rapport de compatibilité généré automatiquement

Chaque job de la matrice installe une version différente de LearnDash via Composer, dans un environnement WordPress jetable. La configuration ressemble à ceci :

```
jobs:
  test:
    strategy:
      matrix:
        learndash: ["4.4.0", "4.7.0", "4.9.0-beta1"]
    steps:
      - run: composer require learndash/learndash-core:${{ matrix.learndash }}
      - run: vendor/bin/phpunit --testsuite integration
```

La version bêta n'est pas disponible sur un dépôt Composer public : elle est récupérée depuis une archive privée fournie par l'éditeur, ce qui impose de la stocker dans un registre interne plutôt que de la copier dans le dépôt du plugin.

### Isoler les fixtures par test

Chaque test crée son propre cours, son propre utilisateur et sa propre inscription plutôt que de réutiliser un jeu de données partagé. Cette isolation coûte quelques millisecondes par test, mais elle évite qu'un échec sur la version bêta contamine les deux autres jobs qui tournent en parallèle.

- Une factory `create_course_with_lesson()` commune aux trois jobs
- Un nettoyage systématique via `wp_delete_post()` en fin de test
- Aucune dépendance à l'ordre d'exécution des tests

## Gérer les divergences d'API entre versions

La version bêta a renommé un filtre : `learndash_process_mark_complete` est devenu `ld_lesson_completed` dans une release candidate, avant d'être partiellement annulé au retour des utilisateurs. Sans la matrice, ce changement serait passé complètement inaperçu jusqu'à la sortie officielle.

La stratégie retenue : un adaptateur interne qui détecte la version de LearnDash active via `defined( 'LEARNDASH_VERSION' )` et bascule sur le bon nom de filtre. Les tests valident que l'adaptateur choisit la bonne branche, pas seulement que le comportement final est correct.

### Documenter les écarts constatés

Chaque échec de la matrice bêta génère un rapport texte archivé comme artefact de build, avec le diff exact entre le comportement attendu et observé. Ce rapport sert de base à un ticket transmis au support de l'éditeur, avec repro minimal.

> Une matrice de compatibilité ne remplace pas la veille sur le changelog de l'éditeur : elle la confirme, ou la contredit, avec des faits reproductibles.

## Ce que la suite ne couvre pas

Le suivi de progression personnalisé qui vit entièrement côté plugin, sans dépendance à LearnDash, reste testé séparément dans une suite unitaire classique. Mélanger les deux aurait ralenti chaque exécution sans bénéfice réel : les tests contre la matrice de versions ne concernent que la frontière avec l'extension tierce.

De la même façon, les tests de performance de LearnDash lui-même n'entrent pas dans ce périmètre ; seule la robustesse de l'intégration est vérifiée ici.

## En résumé

Trois versions dans la matrice, un adaptateur qui absorbe les divergences, des fixtures isolées par test : ce dispositif a détecté deux ruptures d'API en huit mois, toutes les deux avant leur sortie stable. Le coût d'exécution supplémentaire — environ quatre minutes par run de CI — reste largement inférieur au coût d'un correctif publié en urgence après un signalement client.