ex 1 et 3 en cours (todo ex 2)

This commit is contained in:
trochas
2025-12-05 09:55:50 +01:00
parent 7155dd77be
commit d6bd1db6bc
4 changed files with 47 additions and 0 deletions

1
.gitignore vendored Normal file
View File

@@ -0,0 +1 @@
target/

View File

@@ -5,7 +5,17 @@ public class StringUtils {
private StringUtils() {}
public static boolean isBalanced(String str) {
return false;
}
public static String reqIsBalanced(String str){
String all = "[\\[\\(\\{\\]\\)\\}\"]";
String openRegex = "[\\[\\(\\{\"]";
String closeRegex = "[\\]\\)\\}\"]";
String regex = "^[^"+all+"]*"+openRegex+"."+closeRegex+"^["+all+"]*";
return str;
}
}

View File

@@ -8,4 +8,12 @@ import static org.junit.jupiter.api.Assertions.*;
class StringUtilsTest {
@Test
public void test2(){
//assertEquals(num1,num2);
String s = "te";
String s2 = "test";
s += "st";
assertSame(s2,s);
}
}

View File

@@ -11,3 +11,31 @@ Answer the following questions:
4. In JUnit 4, an exception was expected using the `@Test` annotation, while in JUnit 5 there is a special assertion method `assertThrows`. In your opinion, what are the advantages of this new way of checking expected exceptions?
## Answer
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
2.
assertEquals vérifie si les valeurs des objets sont identiques alors que assertSame vérifie si l'objet est identique.
Par exemple
```java
String s = "test";
assertSame(s,s);
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");
```
assertSame renvoit false, alors que assertEquals renvoit true
3.
4.
Cela permet de rendre les test plus uniforme, dans junit 5 on comprend mieux où exactement on attend l'exception.