La plupart des développeurs qui ont ajouté des fonctionnalités à la plate-forme edx connaissent ModuleStoreTestCase. Si vos tests portent sur le contenu du didacticiel (même s'il ne s'agit que de créer un cours vide), l'héritage de cette classe garantira que les données seront correctement nettoyées entre les tests individuels. Ceci est extrêmement précieux, mais peut également être un gaspillage dans de nombreuses situations. Lors du hackathon de la semaine dernière, j'ai créé une alternative plus rapide appelé SharedModuleStoreTestCaseSharedModuleStoreTestCase.
Contrairement à ModuleStoreTestCase, SharedModuleStoreTestCaseSharedModuleStoreTestCase ne fait que ModuleStore nettoyage au TearDownClass() niveau. Il est destiné à être utilisé dans des situations où un ou une petite poignée de cours peuvent être initialisés à l'avance, puis partagés en lecture seule sur de nombreux tests. Ce modèle d'utilisation se retrouve couramment dans les tests LMS, qui recréent souvent simplement le même cours encore et encore dans leur mettre en place() méthodes.
Impact sur les performances
Pour avoir une idée de l'effet que cela pourrait avoir, j'ai basculé quelques modules de test dans le cadre de mon travail de hackathon. Ce ne sont que des chiffres approximatifs, car ils sont basés sur un nombre relativement restreint de tests Jenkins. Cela dit, les résultats sont prometteurs :
| Fichier | # Essais | Avant | Après | Delta |
| lms/djangoapps/ccx/tests/test_ccx_modulestore.py | 5 | 38s | 4s | -89% |
| lms/djangoapps/discussion_api/tests/test_api.py | 409 | 2m 45s | 51s | -69% |
| lms/djangoapps/teams/tests/test_views.py | 152 | 1m 17s | 33s | -57% |
Alors, comment convertissez-vous vos propres tests ?
Faire le commutateur
La plupart des classes qui héritent de ModuleStoreTestCase commencer quelque chose comme ça :
Si vous modifiez auto.cours dans vos fonctions de test individuelles, alors c'est parfait, et vous devriez continuer à utiliser ModuleStoreTestCase. Cependant, si vous ne configurez le cours qu'une seule fois et que vous le traitez en lecture seule dans vos tests, vous pouvez désormais le faire à la place :
Il est important que les opérations Django ORM restent dans mettre en place(). Tous les modèles que vous créez dans setUpClass() doit être supprimé manuellement dans votre TearDownClass() méthode - SharedModuleStoreTestCaseSharedModuleStoreTestCase ne les nettoiera pas correctement. Même si vous faites attention, vous êtes toujours susceptible de casser d'autres tests dans le système de manière imprévisible, car ils font de mauvaises hypothèses sur les séquences et les identifiants qui seront créés lors de la configuration de leurs données. Cela peut être extrêmement fastidieux à déboguer.
Lors de la mise à niveau vers Django 1.8, vous pourrez utiliser setUpTestData() pour effectuer en toute sécurité une initialisation au niveau de la classe des modèles Django avec nettoyage automatique. Veuillez attendre cette mise à jour et placer les manipulations de modèle dans mettre en place() pour l'instant, même si c'est un peu plus lent.
Quels tests dois-je convertir ?
L'endroit le plus simple pour rechercher des cibles d'optimisation de test est le Rapport de construction de test Jenkins. Cliquez sur "Durée" pour trier par cette colonne.
Nous voulons principalement cibler des tests coûteux qui créent des données de cours complexes (par exemple CCX) ou qui ont des données de cours simples mais de très nombreux tests (par exemple des discussions). Créer même le cours le plus simple prend environ 250 à 300 ms environ, ce qui s'additionne vraiment lorsque vous utilisez des outils comme ddt qui multiplient effectivement le nombre de tests dans une classe.
À emporter global
L'accès à la base de données est une partie coûteuse de l'exécution des tests, et le ModuleStore en est un parfait exemple. J'espère que SharedModuleStoreTestCaseSharedModuleStoreTestCase peut être un outil utile pour réduire les temps d'exécution des tests. Mais au-delà de cela, j'espère que comprendre pourquoi cela fonctionne nous permettra de concevoir des suites de tests plus rapides en général.
Dave Ormsbee est architecte senior chez edX. Cet article a été initialement publié sur son blog, Swamp Castle.
