Differences

This shows you the differences between two versions of the page.

--- 2019_2020:s3:methodo:td:env1:tests [2019/08/25 13:47] – [Couverture des tests] blay
+++ 2019_2020:s3:methodo:td:env1:tests [2019/08/25 14:24] (current) – [Eclipse et couverture de tests] blay
@@ Line 2: / Line 2: @@
 ====== Tests en Java - Rappel ou Apprentissage ======
-Voir pour plus de détail le livre p. 96 de ISBN 978-3-030-24094-3, Introduction to Software Design with Par  Robillard, Martin P.
+.
+<note warning>Voir pour plus de détail le livre à partir de la page 96 de ISBN 978-3-030-24094-3, Introduction to Software Design with Par Robillard, Martin P.
 Il devrait être disponible à la bibliothèque et vous trouverez une version électronique en ligne. (voir plus bas dans la catégorie référence).
-**Beaucoup des éléments qui suivent en sont une simple traduction.**
+**L'essentiel des éléments qui suivent en sont une simple traduction.**
+</note>
 ===== Structuration d'une suite de tests =====
@@ Line 124: / Line 129: @@
 Cependant, les branches vraies et fausses conduisent toutes deux à des instructions qui sont constituées d'expressions booléennes, qui sont elles-mêmes un autre type de branche. Pour être cohérent avec les outils populaires d'analyse de l'âge de couverture, j'adopte la définition que les expressions booléennes dans les instructions introduisent également des branches. Bien que plus complexe à déterminer, cette définition est également plus utile. Avec cette définition, le code original de ''canMoveTo'' présente huit branches : le si, le premier relevé de retour, la première comparaison dans le deuxième relevé de retour, et la deuxième comparaison dans le deuxième relevé de retour. Chacune de ces branches a un résultat vrai et faux. Le seul test écrit jusqu'à présent ne couvre que 3/8 = 37,5 % des branches.
+D'une manière générale, la couverture des branches est l'un des critères de couverture des tests les plus utiles. Elle est bien étayée par des outils de test et relativement facile à interpréter, et englobe également la couverture des instructions, ce qui signifie qu'obtenir une couverture complète des instructions implique toujours une couverture complète des branches.
+==== Eclipse et couverture de tests ====
+[[https://www.eclemma.org/|EclEmma]] est un outil gratuit de couverture de code Java pour Eclipse, disponible sous la licence publique Eclipse. Il apporte l'analyse de couverture de code directement dans l'atelier Eclipse.
+Depuis la version 2.0, EclEmma est basé sur la bibliothèque de codes JaCoCoCo. L'intégration d'Eclipse a pour but d'aider le développeur individuel de manière hautement interactive.
+Vous avez différents types de compteurs à disposition (voir https://www.jacoco.org/jacoco/trunk/doc/counters.html):
 {{:2019_2020:s3:methodo:td:env1:capture_d_e_cran_2019-08-25_a_15.28.57.png?200|}}
+{{:2019_2020:s3:methodo:td:env1:capture_d_e_cran_2019-08-25_a_16.05.07.png?200|}}
+et pour mieux comprendre les codes en couleur : https://www.eclemma.org/userdoc/annotations.html
+==== Sélection des cas de tests ====
 Aujourd'hui il y a deux façons fondamentales d'aborder la sélection des cas de test :
@@ Line 130: / Line 151: @@
     * Les **tests fonctionnels (ou de boîte noire)** tentent de couvrir autant que possible le comportement spécifié d'un programme, en se basant sur certaines spécifications externes de ce que le programme doit faire en particulier au travers de post-condition(Nous verrons également que dans le processus de production d'un programme, on prévoit des tests à réaliser dans les histoires utilisateurs). Les tests de boîte noire présentent de nombreux avantages, notamment le fait qu'il n'est pas nécessaire d'accéder au code, que les tests peuvent révéler des problèmes dans la spécification.
     * Les **tests structurels (ou de boîte blanche)** tentent de couvrir autant que possible le comportement implémenté d'un programme, sur la base d'une analyse du code source de l'unité à tester. Le principal avantage du test des boîtes blanches est qu'il peut révéler des problèmes causés par des détails d'implémentation de bas niveau qui sont invisibles au niveau de la spécification.