# Question 1 #### Junit 5.7 L'étape 6 de la configuration dans le README.md (`Ajouter JUnit5.7 au classpath (proposé par intellij via un des fichiers de test)`) donne cette consigne. Autrement dit, rendez-vous sur un fichier de test peu importe lequel et rajoutez la dépendance manquante (soulignée en rouge) au class path à l'aide d'intellij (Add Junit 5.4 to Classpath). #### Configuration Run/Debug Nous n'avons pas eu besoin de configurer le run. Une fois toutes les étapes du README.md réalisées, nous avons simplement exécuté la classe Main (clic droit sur le fichier Main -> run). #### Assurer le bon fonctionnement du projet Nous avons détaillé les étapes clairement dans le README.md. Nous avons également testé que le projet soit fonctionnel à partir d'un nouveau clone (installation vierge). #### Que faire de plus ? * Un tuto vidéo. * Consacrer du temps pour se renseigner, afin de savoir si IntelliJ permet de faire cela "automatiquement" à partir de fichiers de configurations. # Question 2 #### Attributs statiques MainController Tous les objets de type `MainController` ont besoin d'un objet `BorderPane` et `Stage` qui correspondent à la fenêtre de l'application. Étant donné que les objets de `MainController` sont créés un peu partout dans le programme (à chaque changement de fenêtre depuis un autre controller), en mettant ces attributs statiques, nous n'avons pas besoin de nous occuper de ces arguments dans toutes les instances. Ainsi, l'utilisation du programme est nettement simplifiée. #### Faut-il changer cela? Dans le cas où nous devions gérer plusieurs fenêtres à la fois (par exemple, une fenêtre qui liste les projets affichés en même temps que le calendrier), il aurait été nécessaire de mettre ces attributs dynamiques. Dans ce cas, nous pourrions avoir plusieurs instances de `Stage` et de `BorderPane` pour différentes instances de `MainController`. #### Nom `MainController` Nous trouvons ce nom correcte. Le `MainCrontrolleur` est une classe dont tous les controlleurs héritent. Il ne sera jamais utilisé comme object direct (classe abstraite). Il s'agit donc du controlleur posèdant les méthodes principales/"main" qui devrons être utilisés par tous les controlleurs de fenêtres. # Question 3 #### Couverture Selon nous, la couverture des tests est bonne. Les classes du modèle sont bien testées à l'exception des classes du cloud. Les classes des controllers ne sont quasiment pas testées étant données qu'elles sont directement liées à la vue. Seules les méthodes testables des controller (qui n'agissent pas sur la vue) ont donc été testées. Pour ce qui est des tests du cloud, l'environnement de test est trop complexe à écrire (en plus de devoir créer un compte Dropbox uniquement pour les tests). Dans l'état actuel des choses, l'utilisateur doit interagir avec son navigateur internet pour se connecter et générer un token. Tester les méthodes liées au cloud aurait nécessité d'automatiser la connexion à un compte Dropbox et la récupération d'un token. Nous avons donc préféré consacrer notre temps à faire un code propre et complet avec une bonne intégration graphique. Pour les classes `ProjectImport` et `ProjectExporter`, la couverture est faible vu que la majorité des méthodes sont des getter/setters ou des simples appels à des méthodes testées plus loin. #### Amélioration Pour plusieurs méthodes, seul le cas normal d'utilisation est testé. Nous n'avons pas toujours testé les cas qui doivent renvoyer des exceptions. Par exemple, dans le fichier [ProjectTest.java](test/be/ac/ulb/infof307/g08/objects/ProjectTest.java) la méthode `setName` ne vérifie que si le nom est bien changé si l'on donne un nouveau nom de projet valide. Nous aurions dû rajouter un test qui vérifie que que si l'on essaie de mettre un nom invalide, une exception soit bien levée. D'autres exemples où le cas qui devrait renvoyer une exception n'est pas testé: * Dans [DBExporterTest.java](test/be/ac/ulb/infof307/g08/import_export/DBExporterTest.java) ne vérifie pas qu'une exception est bien levée si le fichier exporté ne peut pas être créé (par exemple sans les permissions en écriture sur le dossier) * Dans [UserTest.java](test/be/ac/ulb/infof307/g08/objects/UserTest.java) ne teste pas le cas où l'on supprime une invitation qui n'existe pas (ce n'est pas grave dans ce cas car l'utilisateur n'aura jamais cette possibilité). * etc... # Question 4 #### Pourquoi le singleton Initialement, nous avions implémenté des classes statiques à la place des singletons pour les classes dont une seule instance devait exister et dont les méthodes devaient être accessibles de partout. Le problème de cette méthode est que nous ne pouvions pas profiter des avantages de l'orienté objet (polymorphisme, encapsulation, héritage). L'utilisation de singletons nous offre ces avantages supplémentaires. #### Alternative Avec le Factory Pattern qui aurait géré la création de nos classes "statiques". De cette manière l'abstraction du "statique" aurait été total étant donné que juste la factory est au courant qu'il n'existe qu'un seul objet de cette classe. Les autres pensent qu'ils ont un nouvel objet. Cependant, cette méthode augmente la complexité du code et dans notre cas, nous pensons que ce n'est pas nécéssaire. # Question 5 Étant donné que la classe `DashBoardController` s'occupe de l'affichage des statistiques globales et locales et de leur export, nous aurions pû avoir 3 classes. Une classe mère `DashBoardController` qui s'occuperait de l'affichage des statistiques communes et 2 classes filles pour différencier les statistiques locales et globales. De plus, nous aurions pû créer une classe différente pour l'export des données, de sorte que ce ne soit pas à la classe `DashBoardController` de créer les fichiers à exporter.