correction

code/tp3-balanced-strings/src/test/java/fr/istic/vv/StringUtilsTest.java

@@ -104,4 +104,5 @@ class StringUtilsTest {
         String prog1 = "for(int i = 0;i<10; i++){System.out.println(\"tab[i]\");]";
         assertFalse(isBalanced(prog1));
     }
-}
+
+}

exercises/assertions.md

@@ -14,6 +14,7 @@ Answer the following questions:
 
 1.
 Les flottants sont codés en binaire avec des divisions de 2, certaines valeurs sont donc impossibles à avoir exactement en flottant, comme 1.2 et 0.4
+Pour être sûr que 2 flottant sont identiques, il faut qu'ils soient passés par les mêmes opérations.
 
 2.
 assertEquals vérifie si les valeurs des objets sont identiques alors que assertSame vérifie si l'objet est identique.
@@ -26,11 +27,12 @@ assertEquals(s,s);
 revoient true
 alors que
 ```java
-String s = "te";
-String s2 = "test";
-        s += "st"; //sinon l'optimisation du compilateur Java met le même objet sur s et s2
-assertSame("test",str+"st");
-assertEquals("test",str+"st");
+String s1 = "un ancien string"; //sinon Java réutilise le même objet "test" pour s1 et s2
+String s2 = "";
+s1 = "test";
+s2 = "test";
+assertSame(s1,s2);
+assertEquals(s1,s2);
 ```
 assertSame renvoit false, alors que assertEquals renvoit true
 

exercises/mocks.md

@@ -15,4 +15,4 @@ Propose a solution to this problem in your new Mockito-based test cases.
 
 Aucun test n'échoue quand on supprime le contenu de prepareSocket() car les tests ne vérifient les conditions seulement si setEnabledProtocols se lance, or si prepareSocket() est vide setEnabledProtocols n'est jamais appelé, donc ni le fail(), ni le assertTrue() n'est exécuté. Le test passe donc.
 
-avec les Mock on utilise verify. Si setEnabledProtocols n'est jamais appelé alors c'est aussi une erreur
+Avec les Mock, on utilise verify. Si setEnabledProtocols n'est jamais appelé, alors c'est aussi une erreur

exercises/pmd-test-smells.md

@@ -25,7 +25,7 @@ On lance la commande
 ./test_folder/commons-math/commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/stat/regression/MillerUpdatingRegressionTest.java:559:	DetachedTestCase:	Probable detached JUnit test case.
 `
 ---
-On a pris le 1ere erreur: 
+On a pris la première erreur : 
 ```
     public void testConcatenateEmptyArguments() {
         final double[] x = new double[] {0, 1, 2};
@@ -39,8 +39,8 @@ On a pris le 1ere erreur:
     }
 ```
 
-On peut voir quand il n'a pas l'annotation `@Test` au début de class test donc normalement le test 
-qu'il a fait mais JUnit n'execute pas. 
+On peut voir que quand il n'y a pas l'annotation `@Test` au début de la class test
+JUnit ne l'exécute donc pas.
 
 Voici la correction: 
 ```

exercises/test-date-class.md

@@ -75,8 +75,9 @@ compareTo : On teste une différence pour un jour différent, un mois différent
 
 2.
 Avec la coverage, on a pu détecter une vérification redondante et une condition inutile qui généraient du code mort, et une opération boolean inutile dans une condition
+
 3.
-La coverage précédent nous apermis de detecter un opérateur inutile. Les autre condition n'on qu'un seul opérateure.
+La coverage précédente nous a permis de détecter un opérateur inutile. Les autres conditions n'ont qu'un seul opérateur.
 
 4.
 En lançant PIT, tous les mutants générés ont été tués.