GroovyMorning_RLAC

Tests End-to-End (E2E) : Simuler une radio pour valider le pipeline

Le développement d’un système combinant Java, Python, FFmpeg, des bases de données et des modèles d’IA nécessite une attention particulière à la stabilité. Afin de s’assurer que les modifications n’impactent pas le bon fonctionnement global, un environnement de Simulation a été mis en place.

Philosophie des tests dans GroovyMorning

Les tests unitaires, bien que nécessaires, s’avèrent insuffisants pour valider la chaîne de vie d’une chronique. Un environnement de test End-to-End (E2E), totalement isolé sous Docker, a donc été créé.

Simulation du Direct Radio

Le défi majeur réside dans l’aspect Live. L’attente d’une diffusion réelle sur France Inter pour tester le code est évitée grâce à l’utilisation d’un fichier audio de référence (test_flux.wav). Ce fichier contient :

1. Des passages de silence.
2. Un jingle réel.
3. Une séquence parlée.
4. Un jingle de fin.

Ce fichier est injecté dans le système via un pipe Unix (/tmp/audio_pipe), simulant le comportement d’un flux radio en direct pour les services.

Orchestration avec Docker Compose

Une infrastructure complète est déployée en quelques secondes pour chaque exécution de test :

• Postgres : Stockage des plannings de test.
• GMFM-Recorder (Java) : Test de la capture.
• GMFM-Segmenter (Python) : Test de l’IA.
• Test Runner (Python) : Coordination de l’ensemble.

Scénario de Test

Le script test_runner.py exécute les étapes suivantes :

1. Initialisation : Injection d’un planning fictif dans la base de données.
2. Injection : Lancement de la lecture du fichier audio test_flux.wav.
3. Surveillance : Interrogation régulière de l’API Java pour détecter l’apparition d’une nouvelle chronique.
4. Validation : Vérification de la génération du fichier .m3u8 sur le disque et de la correspondance de sa durée avec les données injectées.

Intérêt du pipeline

Ce pipeline de test permet de :

• Valider les régressions : S’assurer que les optimisations n’entravent pas la communication entre les composants.
• Tester des cas limites : Vérifier le comportement en cas de coupure de connexion ou de modification légère des jingles.
• Indépendance du Cloud : L’exécution locale évite les frais d’API (comme DeepSeek) pour les tests fréquents, grâce à l’usage de mocks ou de modèles locaux légers.

Conclusion

L’approche par simulation sécurise le déploiement de GroovyMorning. Chaque modification est validée par une simulation de radio réelle, garantissant la disponibilité des chroniques pour l’utilisateur final.

This site is open source. Improve this page.