2025 init

exercises/assertions.md

@@ -0,0 +1,13 @@
+# On assertions
+
+Answer the following questions:
+
+1. The following assertion fails `assertTrue(3 * .4 == 1.2)`. Explain why and describe how this type of check should be done.
+
+2. What is the difference between `assertEquals` and `assertSame`? Show scenarios where they produce the same result and scenarios where they do not produce the same result.
+
+3. In classes we saw that `fail` is useful to mark code that should not be executed because an exception was expected before. Find other uses for `fail`. Explain the use case and add an example.
+
+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

exercises/balanced-strings.md

@@ -0,0 +1,28 @@
+# Balanced strings
+
+A string containing grouping symbols `{}[]()` is said to be balanced if every open symbol `{[(` has a matching closed symbol `)]}` and the substrings before, after and between each pair of symbols is also balanced. The empty string is considered as balanced.
+
+For example: `{[][]}({})` is balanced, while `][`, `([)]`, `{`, `{(}{}` are not.
+
+Implement the following method:
+
+```java
+public static boolean isBalanced(String str) {
+    ...
+}
+```
+
+`isBalanced` returns `true` if `str` is balanced according to the rules explained above. Otherwise, it returns `false`.
+
+Use the coverage criteria studied in classes as follows:
+
+1. Use input space partitioning to design an initial set of inputs. Explain below the characteristics and partition blocks you identified.
+2. Evaluate the statement coverage of the test cases designed in the previous step. If needed, add new test cases to increase the coverage. Describe below what you did in this step.
+3. If you have in your code any predicate that uses more than two boolean operators, check if the test cases written so far satisfy *Base Choice Coverage*. If needed, add new test cases. Describe below how you evaluated the logic coverage and the new test cases you added.
+4. Use PIT to evaluate the test suite you have so far. Describe below the mutation score and the live mutants. Add new test cases or refactor the existing ones to achieve a high mutation score.
+
+Write below the actions you took on each step and the results you obtained.
+Use the project in [tp3-balanced-strings](../code/tp3-balanced-strings) to complete this exercise.
+
+## Answer
+

exercises/binary-heap.md

@@ -0,0 +1,42 @@
+# Implementing and testing a binary heap
+
+A [*binary heap*](https://en.wikipedia.org/wiki/Binary_heap) is a data structure that contains comparable objects and it is able to efficiently return the lowest element.
+This data structure relies on a binary tree to keep the insertion and deletion operations efficient. It is the base of the [*Heapsort* algorithm](https://en.wikipedia.org/wiki/Heapsort).
+
+Implement a `BinaryHeap` class with the following interface:
+
+```java
+class BinaryHeap<T> {
+
+    public BinaryHeap(Comparator<T> comparator) { ... }
+
+    public T pop() { ... }
+
+    public T peek() { ... }
+
+    public void push(T element) { ... }
+
+    public int count() { ... }
+
+}
+```
+
+A `BinaryHeap` instance is created using a `Comparator` object that represents the ordering criterion between the objects in the heap.
+`pop` returns and removes the minimum object in the heap. If the heap is empty it throws a `NotSuchElementException`.
+`peek` similar to `pop`, returns the minimum object but it does not remove it from the `BinaryHeap`.
+`push` adds an element to the `BinaryHeap`.
+`count` returns the number of elements in the `BinaryHeap`.
+
+Design and implement a test suite for this `BinaryHeap` class.
+Feel free to add any extra method you may need.
+
+Use the following steps to design the test suite:
+
+1. With the help of *Input Space Partitioning* design a set of initial test inputs for each method. Write below the characteristics and blocks you identified for each method. Specify which characteristics are common to more than one method.
+2. Evaluate the statement coverage of the test cases designed in the previous step. If needed, add new test cases to increase the coverage. Describe below what you did in this step.
+3. If you have in your code any predicate that uses more than two boolean operators check if the test cases written to far satisfy *Base Choice Coverage*. If needed add new test cases. Describe below how you evaluated the logic coverage and the new test cases you added.
+4. Use PIT to evaluate the test suite you have so far. Describe below the mutation score and the live mutants. Add new test cases or refactor the existing ones to achieve a high mutation score.
+
+Use the project in [tp3-heap](../code/tp3-heap) to complete this exercise.
+
+## Answer

exercises/mocks.md

@@ -0,0 +1,11 @@
+# Mocks to the rescue
+
+The classes `SSLSocket`, `TLSProtocol` and `TLSSocketFactory` are included in the `sockets` package of the [`tp3-ssl`](../code/tp3-ssl) project.
+
+The test class `TLSSocketFactoryTest` tests `TLSSocketFactory` and manually builds stubs and mocks for SSLSocket objects.
+
+Rewrite these tests with the help of Mockito.
+
+The initial tests fail to completely test the `TLSSockeetFactory`. In fact, if we *entirely* remove the code inside the body of `prepareSocket` no test case fails.
+
+Propose a solution to this problem in your new Mockito-based test cases.

exercises/pmd-test-smells.md

@@ -0,0 +1,17 @@
+# Detecting test smells with PMD
+
+In folder [`pmd-documentation`](../pmd-documentation) you will find the documentation of a selection of PMD rules designed to catch test smells.
+Identify which of the test smells discussed in classes are implemented by these rules.
+
+Use one of the rules to detect a test smell in one of the following projects:
+
+- [Apache Commons Collections](https://github.com/apache/commons-collections)
+- [Apache Commons CLI](https://github.com/apache/commons-cli)
+- [Apache Commons Math](https://github.com/apache/commons-math)
+- [Apache Commons Lang](https://github.com/apache/commons-lang)
+
+Discuss the test smell you found with the help of PMD and propose here an improvement.
+Include the improved test code in this file.
+
+## Answer
+

exercises/test-date-class.md

@@ -0,0 +1,55 @@
+# Test the Date class
+
+Implement a class `Date` with the interface shown below:
+
+```java
+class Date implements Comparable<Date> {
+
+    public Date(int day, int month, int year) { ... }
+
+    public static boolean isValidDate(int day, int month, int year) { ... }
+
+    public static boolean isLeapYear(int year) { ... }
+
+    public Date nextDate() { ... }
+
+    public Date previousDate { ... }
+
+    public int compareTo(Date other) { ... }
+
+}
+```
+
+The constructor throws an exception if the three given integers do not form a valid date.
+
+`isValidDate` returns `true` if the three integers form a valid year, otherwise `false`.
+
+`isLeapYear` says if the given integer is a leap year.
+
+`nextDate` returns a new `Date` instance representing the date of the following day.
+
+`previousDate` returns a new `Date` instance representing the date of the previous day.
+
+`compareTo` follows the `Comparable` convention:
+
+* `date.compareTo(other)` returns a positive integer if `date` is posterior to `other`
+* `date.compareTo(other)` returns a negative integer if `date` is anterior to `other`
+* `date.compareTo(other)` returns `0` if `date` and `other` represent the same date.
+* the method throws a `NullPointerException` if `other` is `null` 
+
+Design and implement a test suite for this `Date` class.
+You may use the test cases discussed in classes as a starting point. 
+Also, feel free to add any extra method you may need to the `Date` class.
+
+
+Use the following steps to design the test suite:
+
+1. With the help of *Input Space Partitioning* design a set of initial test inputs for each method. Write below the characteristics and blocks you identified for each method. Specify which characteristics are common to more than one method.
+2. Evaluate the statement coverage of the test cases designed in the previous step. If needed, add new test cases to increase the coverage. Describe below what you did in this step.
+3. If you have in your code any predicate that uses more than two boolean operators check if the test cases written to far satisfy *Base Choice Coverage*. If needed add new test cases. Describe below how you evaluated the logic coverage and the new test cases you added.
+4. Use PIT to evaluate the test suite you have so far. Describe below the mutation score and the live mutants. Add new test cases or refactor the existing ones to achieve a high mutation score.
+
+Use the project in [tp3-date](../code/tp3-date) to complete this exercise.
+
+## Answer
+