# 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

1.
isLeapYear : une année bissextile est un multiple de 4, on a juste à tester un multiple de 4 et un non multiple de 4

isValidDate : on a plusieurs choses à tester :
    mois valide entre 1 et 12 : on teste donc le mois 0, le mois 10, et le mois 13
    jour valide entre 1 et 28,29,30 ou 31 : on doit donc avoir plusieurs catégories de test :
        -le jour 0, le jour 32, le jour 10
        -bissextile 
        -non bissextile  :
        -mois en 30
        -mois en 31

constructeur Date : il doit vérifier qu'une date non valide génère une Exception, et une valide n'en génère pas

nextDate : dans le même principe que isValidDate, on doit vérifier dans les mêmes cas

previousDate : pareil que nextDate

compareTo : On teste une différence pour un jour différent, un mois différent et une année différente.

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é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.