Au cours des 10 derniers mois, les développeurs d'edX ont travaillé dur pour augmenter la couverture des tests automatisés. Nos 2,491 87 tests unitaires Python couvrent actuellement XNUMX % des lignes du référentiel de la plateforme edx. Ces tests, ainsi que nos tests d'acceptation Selenium et nos tests unitaires JavaScript, s'exécutent sur chaque demande d'extraction, ce qui nous permet de valider rapidement les modifications de code proposées.
Comment avons-nous augmenté la couverture des tests de moins de 50 % à 87 % en seulement 10 mois ? Une partie de la réponse est un outil appelé diff-couverture.
Dans un flux de travail typique, un développeur travaillant sur un grand projet peut faire une demande d'extraction qui modifie quelques dizaines de lignes de code. Avant le changement, la couverture des tests pouvait être de 72 % ; après, il pourrait encore être de 72 %. La taille du projet rend difficile de voir l'effet d'une seule pull request. Diff-cover vous permet de vous concentrer sur les mesures de qualité d'une seule demande d'extraction plutôt que sur le projet dans son ensemble.
Diff-cover mesure les lignes de code dans un git diff. Pour une proposition de modification du code, il vous indiquera quelles lignes modifiées manquent de couverture. C'est une idée simple, mais elle a des implications puissantes :
- Pour les développeurs, diff-cover fournit une métrique claire et réalisable : si vous touchez une ligne de code, elle doit être couverte.
- Pour les réviseurs de code, diff-cover permet de vérifier plus facilement que les développeurs écrivent des tests pour toutes les modifications de code.
En se concentrant sur la couverture des différences, les développeurs peuvent faire de petits pas visibles vers l'amélioration de la couverture mondiale. Un engagement particulier peut augmenter de défis couverture d'une fraction de pour cent seulement, mais toujours 95 % diff couverture. Lentement mais sûrement, alors que les développeurs écrivaient des tests pour leurs modifications de code, la couverture mondiale a également commencé à augmenter. En conséquence, nous avons pu détecter certains types de bogues plus tôt.
Plus important encore, d'autres développeurs ont commencé à contribuer à diff-cover lui-même et à s'approprier l'outil. Par exemple, Cale a généralisé l'outil pour prendre en charge des contrôles de « qualité » supplémentaires, et Sarina l'a étendu pour signaler les violations pep8 et Pylint dans un diff. De nombreux autres développeurs ont fourni des commentaires et des suggestions lors d'un premier test bêta de diff-cover. L'outil est devenu un point de départ pour un réexamen de nos normes de révision et de test de code, ce qui a conduit à un véritable changement dans notre culture de test.
Bien entendu, la mesure de la couverture présente encore des limites importantes. En particulier, une couverture de diff élevée ne pas garantir un code sans bogue : dans un système étroitement couplé, la modification d'un composant peut avoir des conséquences importantes et imprévues sur d'autres parties du système, même si le code modifié est couvert à 100 %. Dans de tels cas, les tests d'intégration peuvent détecter des bogues que les tests unitaires pourraient manquer.
Si vous pensez que diff-cover pourrait vous être utile, consultez le projet - il est open-source et disponible sur GitHub. Le code est conçu pour être extensible à d'autres systèmes de contrôle de version et vérificateurs de qualité, alors n'hésitez pas à ajouter des fonctionnalités et à faire une demande d'extraction !
Will Daly est ingénieur de test chez edX. Lorsqu'il ne préconise pas le développement piloté par les tests ou l'optimisation d'un cluster Jenkins, il aime courir le long des rivières et minimiser le nombre de choses dans son appartement.
