La qualité logicielle et l'intégration continue - Cas concret du projet Cytomine
1. La qualité logicielle et
l'intégration continue
Cas concret du projet Cytomine
Loïc Rollus (lrollus@ulg.ac.be), 11/09/2013
2. Présentation
Parcourir les outils d’aide au développement
utilisé pour Cytomine
● Logiciel de gestion de versions
● Tests automatisés
● Framework d’intégration continue
● Système de gestion qualité du code source
● Système de suivi de bugs
● Wiki
4. Au commencement...
Comment
● synchroniser nos sources?
● gérer les conflits entre fichiers?
● faciliter et automatiser les
backups?
● restaurer facilement une version
précédente d’un ou plusieurs
fichiers?
5. Logiciel de gestion de versions
Ou VCS (Version Control System)
● Synchroniser le code source
● Résoudre les conflits
● Gérer les versions du logiciel
● Subversion (serveur, client web, …)
● Git (clients, scripts,...)
Sujet de la précédente réunion des Geek Anonymes:
http://geeksanonymes.argenco.ulg.ac.be/sites/default/files/slides%
20subversion%20and%20GIT.pdf
7. Logiciel de gestion de versions
Comment
● améliorer la robustesse du
code source?
● détecter rapidement les
bugs?
● éviter de tester
manuellement?
● avoir une idée de la qualité
du logiciel?
8. Tests automatisés
● Code destiné à tester des méthodes, classes ou des
fonctionnalités complètes
● Détecter automatiquement et rapidement les bugs en
les exécutant régulièrement
● Test Driven Development: écrire les tests puis
implémenter les fonctionnalités
9. Tests automatisés
● Test unitaire: unité isolée (méthodes, classes,..)
Ex: tester la méthode qui vérifie l’adresse email d’un utilisateur
● Test intégration: plusieurs composantes
Ex: tester l’ajout d’un utilisateur dans la base de données
● Test fonctionnel: fonctionnalités complètes
Ex: lancer le serveur et tester une fonctionnalité via un client
10. Tests automatisés
Pour Cytomine (Junit)
● Test unitaire: pour des librairies, dépendances,...
● Test “hybride” intégration et fonctionnel
● Test fonctionnalités complètes
● Debug “facile”: même application
donc 1 log, exceptions du serveur
récupéré dans les tests, …
● Accès aux classes et fonctionnalités
du serveur (DB, …)
11. Tests automatisés
Schéma classique d’un test
1. Préparation des données
2. Requête HTTP vers Cytomine
3. Analyse de la réponse HTTP
4. Vérification
12. Tests automatisés
Schéma classique d’un test
Exemple: Ajout d’une annotation (zone sur l’image)
1. Préparation des données
a. Création d’un projet et d’une image
b. Création du JSON de l’annotation
2. Requête HTTP vers Cytomine
a. POST HTTP sur l’URL /api/annotation avec le JSON de l’annotation
3. Analyse de la réponse HTTP
a. Vérification du code HTTP (200)
4. Vérification
a. Vérifier directement dans la DB si l’annotation est bien là
13. Tests automatisés
Exemple:
void testAddAnnotationCorrect() {
Annotation annotation = buildAnnotation()
HTTPClient client = initCytomineConnection()
def result = client.post(“/api/annotation”,annotation.toJSON())
assert 200 == result.code
int idAnnotation = result.data.id
assert Annotation.read(idAnnotation)!=null
}
● Tester aussi les listings, les modifications et suppressions.
● Tester aussi les “cas d’échec” (forme non valide, mauvais projet,...).
14. Tests automatisés
Très utile pour les ACL (sécurité)
Exemple :
● Un utilisateur ne peut ajouter ou lire des annotations que dans ses projets.
● Il ne peut modifier ou supprimer que ses annotations.
● L’admin cytomine peut tout faire
1. Critique
2. Difficile à tester manuellement
a. Nombreuses fonctions : add, update, delete, read pour chaque type
de domaine (Annotation, Projet,...)
b. Nombreux rôles : Admin, utilisateur d'un projet, utilisateur du projet qui
a créé l’annotation, utilisateur qui n'a pas accès au projet, anonyme
=> Effectuer la requête et vérifier le code HTTP 200 = succès, 401 = non
authentifié et 403 = non autorisé
17. Système d'intégration Continue
● Bamboo (alternatives: Hudson, Jenkins,...)
● Vérifie tous les x temps (ex : 3min) si le dépôt a été mis à jour
● En cas de mise à jour, Bamboo récupère les dernières sources
● Etapes :
○ Compile+Build+Run Cytomine
○ Compile+Run Test
○ Close Cytomine
OK
Envoyer un mail aux
“responsables”
24. Système de gestion qualité du code source
● Sonar (SonarQube)
● Application web
● Mesurer la qualité du code source en continu
○ Duplications de code
○ Couverture de code par les tests unitaires
○ Mesure le niveau de doc
○ Règles du langage
○ ...
29. Système de gestion qualité du code source
Comment
● répertorier les bugs (test échoué,
plainte utilisateur,...)?
● assurer le suivi de la qualité?
30. Système de suivi de bugs
● Jira
● Gestion par tickets (bug, feature, task,...)
○ Ouvrir, Assigner, Résoudre, Clôturer, ...
○ Organisation et gestion du temps
○ Discussions sur un ticket
33. Résumé
● Logiciel de gestion de versions: Subversion et Git
● Tests automatisés: JUnit
● Framework d’intégration continue: Bamboo
● Système de gestion qualité du code source: Sonar
(Qube)
● Système de suivi de bugs: Jira
● Wiki: Confluence
● Subversion, Git, Junit et Sonar: gratuit
● Bamboo, Jira et Confluence: 10$/an par logiciel si projet
non open-source (self-host, max 10 users, charity :-)...)
34. Tips
● Commencer dès le début du projet
● Test Driven Development
● Ne pas se focaliser (trop) sur les chiffres
35. Amélioration
● Améliorer la couverture des tests du serveur
● Tester l’interface web
● Tester les performances automatiquement
(charge, stress, big data...)