francoislg/glo4002-eq5

Projet de GLO-4002, équipe 5

glo4002-eq5's Issues

enlever les négatifs dans les nom de méthodes

enlever les Not et autre négation dans les nom de méthodes.

Certaines méthodes ne pourrais avoir plus aucun but (apporte rien de nouveau à la clarification ou à l'élégance du code. (oui oui, j'ai bien dit élégance) (oui oui, c'est bien une parenthèse dans une parenthèse so what..)) elle devrons donc être effacées.

passer un objet strategy au lieu davoir une factory

addBoardroom -> add

Enlever les constructeur vide

enlever les generiques du genre worker

2 fois le meme test cant tell where

Changer nom de methode pour comparebynumberofseats

Nom des packages avec lettre MAJ en java

refactor des exceptions dans des packages séparés

Suite au merge de issue18 dans dev (encore des petits conflits wierd à cause du refactor de nom de package) Le refactor des exceptions dans des packages séparés à été écraser.

J'ai donc créer une nouvelle branch que j'ai reseter au commit en question.

Mais avant de relancer le travail, j'aimerais qu'on discute de la chose en question. On en as pas parler et je me pause la question si c'est réellement un bon move... ou s'il n'y aurait pas une meilleur façon (subpackage exception au lieu de 3 nouveau package distinct)

des idées?

Menage issue

Closer ce qui est termine

déplacement des sort et ajout des test #53 manque le sort dans priority booking je pense

protected -> private lorsque s applique

assign -> isAbleToAssign

diviser les méthodes "assign" qui retourne un booléen en "assign" et "isAbleToAssign".

la partie "isAbleToAssign" vérifie la possibilité d'assignation.

la partie "assign" fait le traitement et lance une exception en cas d'erreur.

test de "update" pour les repositorys

En gros... lorsque je persist 2 fois le même objet, il en as juste 1 dans le repo.

Changer addBooking pour add et removeBooking pour remove dans Bookings

déplacer les méthodes de "sort" dans les repository

les répo aurons donc des méthodes comme getBoardroomsOrderedByNumberOfSeats... stuff like that.

séparer les multiples packages pour des sous-modules MAVEN

un sous-module pour la persistence.
un sous-module pour les services.
un sous-module pour le domaine/core.

Verification si on peut ajouter deux boardroom avec le meme nom

Verification si on peut si oui corrige avec un throw d exception
faire un test qui doit throw si on essaye dajouter 2 fois une salle avec le meme nom

BDD, test d'acceptation

Voir Doc de jBehave et Lab sur le sujet https://github.com/jni-/med.

Créer un sous module uat (user acceptance test).
Créer les context
Créer les stories
Créer les Steps (Given When Then)
Créer les fixtures

Cette issue est plutôt général et devrait couvrir TOUTES les users storys "terminé".
Vu la grande charge de travail que cette issue engendre et ma grande lâcheté à ne pas vouloir créer 5 issue pour chaque user story, il en vient donc la responsabilité de TOUS de mener à terme cette issue.

verify -> canAssign

HIBERNATE!!!!!!!!!!!!!!!!!!!!!!!

intégré hibernate et implémenter les répos

maximise -> optimise

Enlever les spys

Corriger le equal en java comme par exemple dans la methode hasname (ismyname)

ismyname -> hasName

runtime exeption pour nos exeptions

Enlever les this sauf dans les constructeurs

BookerStrategies devrait avoir un seul create

qui peut retourner plusieurs strategy avec des parametres

Verification qu'on test bien tout les cas limites

Strategy dans des classes

Changer les boardrooms et bookings en boardroomRepository ect

test d'intégration pour la couche de service

Ajouter le test de equal dans les sorts

Exeption au lieu de Bool dans l assignation

faire nous meme le partern observable

name_of_boardroom1

enlever le 1. remplacer par A_BOARDROOM_NAME ...

Menage des branchs

Closer les desuets et ceux deja merge

format -> sort

identifié les value object et ajouté l'override de .equals

pour la remise3

Ajouter les informations nécessaires au Readme

Noms et matricules de tous les membres de l'équipe
Numéro d'équipe
Liste des scénarios avec leur statut (terminé (et donc correctement testé), en cours …)
Sommaire très court expliquant comment utiliser votre application
Toutes notes que vous désirez transmettre aux correcteurs

Tout mettre en private ce qui est interne

enum pour le priorite

ReservationRepository n'est pas implémenté

Créer le InMemoryRepo

Deplacer le notifier dans boardrooms vers reservations

ENlever le new repo dans boardrooms avec le passe dans le constructeur