Transparents

Transcription

Transparents

Tests et intégration continue
avec Eclipse
Julien Nauroy
Ingénieur Confirmé CDD INRIA – équipe TAO
Laboratoire de Recherche en Informatique
Université Paris Sud
23/05/2013
Quelques mots sur cette présentation
 Contenu à tiers-chemin entre :
 La présentation générale
 Le retour d’expérience
 Le tutoriel (pour référence)
 Plusieurs ambitions




Vous faire découvrir les tests et l’IC dans Eclipse
Vous encourager à les utiliser
Vous fournir un support réutilisable
Vous proposer un retour d’expérience
Tests et intégration continue avec Eclipse
2 / 56
Journée LoOPS de décembre 2012
 Tests de programme par Frédéric Voisin
 Jenkins (intégration continue) par Charles Loomis
 De belles promesses !
 Mais est-ce réellement utile ?
 Est-ce « rentable » quand on développe seul ?
 Quelle intégration dans Eclipse ?
3 / 56
Le projet : un Framework/CMS web PHP
 ~ 7500 lignes, dont 4000 lignes « de code »
 Langage interprété
 Erreurs de syntaxe détectées à l’exécution du code
 Utilisé pour produire des sites web
 Producteur et utilisateur du Framework
 Outil de développement : Eclipse
 Originellement, Netbeans
5 / 56
Plan
1. Mise en place du projet PHP dans Eclipse
2. Ecriture des tests
3. Automatisation des tests
4. Mise en place de l’intégration continue
5. Présentation de l’atelier « tests + IC »
7 / 56
1. Mise en place du projet
Etapes de mise en place d’Eclipse
1. Installation de PDT pour Eclipse
2. Création du projet dans Eclipse
3. Mise en place du débogueur
4. Installation des modules PEAR
5. Installation de Makegood pour tests unitaires
6. Installation des autres outils (checkstyle…)
9 / 56
Les outils Eclipse pour PHP : PDT
10 / 56
Création d’un projet PHP
11 / 56
Réglages du débogueur
12 / 56
Débogueur en fonctionnement
13 / 56
Installation de PEAR et PHPUnit
 PHP Extension and Application Repository
 Equivalent d’un gestionnaire de paquets PHP
 Plusieurs incantations obligatoires
14 / 56
Ajout des libs PEAR dans Eclipse
15 / 56
Installation de Makegood pour PHPUnit
16 / 56
Configuration de Makegood
17 / 56
Installation d’autres outils
18 / 56
Configuration des outils
19 / 56
2. Ecriture des tests
Motivation
 Qu’est-ce qu’un test ?
 « Procédure de vérification partielle d’un système »
 De multiples méthodologies, de multiples objectifs
 Tests unitaires, d’intégration, de performance, de non
régression, de robustesse, de vulnérabilité…
 Ici je ne parlerai que des tests unitaires
 Plus d’infos => voir présentation de Frédéric Voisin
 Pourquoi tester ?
 Besoin de s’assurer de la qualité du programme
 L’impact d’une faille peut être important (web)
 Utilisateurs potentiellement nombreux et anonymes
22 / 56
Cas d’un Framework web
 Tester un Framework web : pas toujours facile !
 Partie « Contrôleur » orientée vers l’extérieur
 Comment la tester ?
 Selon le Framework, la majorité du code peut être
dans le « contrôleur »
 pattern ActiveRecord
 On doit tester la partie serveur (PHP + SQL) mais
également la partie client (HTML + Javascript)
 De nombreuses fonctionnalités => de nombreux
tests à écrire
23 / 56
Du code !
 Un exemple de test unitaire
24 / 56
Faire des tests unitaires, c’est facile !
 Principe : chaque « unité » doit être testée
 Classes, méthodes…
 un standard de facto : xUnit (ici PHPUnit)
 Très grande facilité de prise en main
 Beaucoup de tutoriels disponibles
 xUnit fonctionne par assertions





assertTrue :
l’expression est vraie
assertFalse :
devinez !
assertEquals : deux expressions sont égales
assertCount : une liste a la taille voulue
assertContains : un élément est contenu dans la liste
25 / 56
Bien tester, c’est difficile !
 Il faut penser à tout
 Ajout d’un utilisateur






Le nom de l’utilisateur est valide (nombre de caractères)
Le nom de l’utilisateur n’est pas déjà pris
L’email est valide
L’email n’est pas déjà pris
Pas de syntaxe SQL dans le nom (Injection SQL)
Pas de symboles HTML dans un champ (faille XSS)
26 / 56
Bien tester, c’est difficile !
 Il n’y a pas que les tests unitaires
 Tout l’environnement devrait être testé (base
de données, affichage dans le navigateur,
intégration avec serveur web…)
 Environnement de dev. à mettre en place
 Cela prend beaucoup de temps !
27 / 56
Résultat
 ~1000 lignes de code pour les tests unitaires
 Plusieurs jours de développement
 50 fonctions de test, 567 assertions
28 / 56
Malheureusement…
 Couplage tests + debugger = Code coverage
… Mais pas avec Eclipse + PDT 
29 / 56
Bilan
 Tests unitaires : un peu rébarbatif mais pratique






Force à penser aux cas d’erreur
Permet la non-régression
Plusieurs bugs trouvés en écrivant les tests
Grande aide lors du remaniement du programme
Particulièrement pratique pour du code interprété
Utile et rentable même quand on développe seul
 « Test Continu » : insupportable par défaut !
 Couverture de code : un bel atout
 Aide à cibler les tests
 Ne fonctionne pas dans Eclipse + PDT 
30 / 56
3. Automatisation
Automatiser, kesako ?
 Permet d’exécuter des tâches prédéfinies
 Equivalent d’un fichier « make »
 Actions type « make all » et « make test »
 Aide à la mise en place de l’intégration continue
 Ici, Phing, équivalent PHP de Ant
 Installé via PEAR
32 / 56
Automatiser les outils, pas si facile !
 Phing propose de configurer :






Tests unitaires
Couverture de code
Comptage des lignes de code
Détecteur de copier/coller
Calcul de complexité du code
…
 Du moment que les outils sont présents !
 PHPUnit, Xdebug, PHPLoc, PHPCPD, PHPMD, pear
etc…
33 / 56
build.xml pour Phing
34 / 56
Exécution des tests
35 / 56
4. Intégration continue
Qu’est-ce que l’intégration continue ?
 « L'intégration continue est un ensemble de
pratiques utilisées en génie logiciel consistant à
vérifier à chaque modification de code
source que le résultat des modifications ne
produit pas de régression dans l'application
développée. »
Wikipedia
37 / 56
L’outil d’IC Hudson, pour Stratuslab
38 / 56
Comment ça marche ?
 Un gestionnaire de version héberge le programme
 CVS, SVN, Git, Hg…
 L’outil de gestion de version suit les changements
 Chaque jour, chaque minute, selon un déclencheur…
 A chaque nouvelle version, des actions sont
déclenchées
 Compilation, tests, génération de documentation…
 Exécution possible sur des « esclaves »
 Recommandé !
39 / 56
Quels avantages de l’IC ?
 Les tests sont automatisés
 Un commit SVN => une série de tests
 Historique des tests
 Eventuellement des alertes automatiques si échec
 Le portail peut servir à d’autres fins
 Publication d’un « nightly build »
 Génération de documentation
 Autres tests : compatibilité, performance…
40 / 56
Installer Jenkins
 sudo apt-get install jenkins
OU
 Télécharger fichier JAR
 Java –jar jenkins.jar
 Cliquer « install as a service »
41 / 56
Configurer l’intégration continue
 Configurer une (des) machines(s) + services
 Fastidieux 
1. Configuration de Jenkins
 Installation d’une série de plugins
 Phing, checkstyle, PMD, …
2. Installation des esclaves
3. Configuration des esclaves
 Apache, PHP, mySQL, PEAR, Phing, …
4. Lien entre serveur Jenkins et esclaves
42 / 56
Création d’un nouveau projet
 Choix du nom du projet
 Réglage des paramètres SVN
 Configuration du « build »
 exécution de Phing
 Configuration des étapes post-build
 Graphe tests unitaires
 Graphe couverture de code
 etc
43 / 56
L’interface une fois le projet configuré
44 / 56
Un peu plus tard… vue du projet
45 / 56
Configurer l’outil d’Intégration Continue
 Configurer l’outil, c’est (relativement) facile
 Encore faut-il en maîtriser les arcanes !
 MAIS l’outil ne fait que tracer des graphes
 Il faut générer ces données, automatiquement
 Besoin de la phase d’automatisation
46 / 56
Au final, ça donne quoi ?
47 / 56
Au final, ça donne quoi ?
48 / 56
Jenkins dans Eclipse
49 / 56
50 / 56
51 / 54
Bilan
 Jenkins est complet et peut être complexe
 Mais reste simple pour un petit projet
 Intégration continue pas vitale MAIS :
 Pratique réaliser des actions automatiquement
 build, test, génération de doc…
 Utile pour visualiser les métriques et leur historique
 Encourage à améliorer la qualité du code
 Même pour cette présentation !
 Intérêt de l’intégration de Jenkins dans Eclipse ?
 Visualisations limitées
52 / 56
Les limites
 Adaptation au projet « Grid Observatory » ?
• Acquisition de fichiers à distance
• Traitement des données
• Mise en ligne des données traitées
 Test difficile, beaucoup d’effets de bord
 Le traitement des données est plus facile à tester
 Mais il faut imaginer tous les cas
53 / 56
5. Présentation de l’atelier
Tests + Intégration continue
Qu’allons-nous voir ?
 Création d’un projet simple en Java
 Rédaction de tests avec JUnit
 Couverture de code (pour de vrai)
 Intégration continue
 Le tout en 2h !
55 / 56
Prérequis
 Installer Java 1.6 – 1.7
 Installer Eclipse Juno 4.2
 Installer un client SVN
 Télécharger Jenkins (http://jenkins-ci.org/)
 Si possible, installer Ant
 surtout pour les utilisateurs de Windows
56 / 56

Transparents

Transcription

Documents pareils

Dear Parents, Brussels, 18/03/2015 As you have no doubt

Mitsubishi Eclipse Spyder 2008

TRANSFORMATEURS

nessa hudgf

Imprimer - Garage Daniel Lessard

Mitsubishi Eclipse Spyder 2011

plug-ins Eclipse

Gourmand

876 riverside drive, timmins, on p4n 3w2 pd part 3