par Loïc Rollus et Benjamin Stevens, 11 septembre 2013

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

3. Au commencement...

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

6. Logiciel de gestion de versions

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.
2.
3.
4.
Préparation des données
Requête HTTP vers Cytomine
Analyse de la réponse HTTP
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.
b.
Création d’un projet et d’une image
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é

15. Tests automatisés

16. Tests automatisés
Comment
●
●
exécuter plusieurs
centaines de tests avant
chaque commit?
éviter d’oublier de les
exécuter?

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
OK
○ Compile+Run Test
Envoyer un mail aux
○ Close Cytomine
“responsables”

18. Système d'intégration Continue

19. Système d'intégration Continue

20. Système d'intégration Continue
s
Comment
●
évaluer la quantité de code
testé?

21. Couverture de code
● Cobertura
● Calcul la couverture des tests

22. Couverture de code

23. Couverture de code
Comment
●
évaluer la qualité du code (redondance, règles,...)?

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
...

25. Système de gestion qualité du code source

26. Système de gestion qualité du code source
Click

27. Système de gestion qualité du code source

28. Système de gestion qualité du code source

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

31. Système de suivi de bugs

32. Environnement complet

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...)

36. Fin
?
S
I
T
N
O
U
Q
S
E