É de seguida listado conjunto de testes a efetuar no módulo bank. Nas situações de erro é lançada uma BankException.

• Teste o construtor da classe Bank tal que os argumentos não possam ser null, nem a string vazia, nem brancos, e o código tenha dimensão 4 e seja único 
• Teste o construtor da classe Client tal que os argumentos não possam ser null, nem a string vazia, nem brancos 
  
• Teste o construtor da classe Account tal que os argumentos não possam ser null e o cliente deve pertencer ao banco
  
• Teste o construtor da classe Operation tal que os argumentos não possam ser null e o valor dever ser positivo
• Teste o método deposit para lançar uma exceção se o valor a depositar for negativo ou zero
• Teste o método withdraw para lançar uma exceção se o valor a levantar for negativo, zero ou superior ao saldo
• Teste o método getAccount para lançar exceção para argumentos inválidos, conjunto vazio de contas, várias contas mas nenhuma possui o IBAN enviado

O conjunto de testes a efetuar no módulo activity deve considerar todas as situações de argumentos inconsistentes e ainda as restrições abaixo. Nas situações de erro é lançada uma ActivityException:

• Em ActivityProvider o nome e o código são únicos e o código deve ter 6 carateres
• Em Activity a idade mínima é maior ou igual do que 18 anos e a máxima menor do que 100, a idade mínima não pode ser superior à máxima, e a capacidade deve ser maior que 0
• Em ActivityOffer a data de fim não pode ocorrer antes da data de início
• Na construção de um Booking é necessário garantir que o número de reservas é menor ou igual à capacidade

O conjunto de testes a efetuar no módulo hotel deve considerar todas as situações de argumentos inconsistentes e ainda as restrições abaixo. Nas situações de erro é lançada uma HotelException:

• Em Hotel o código é único e deve ter 7 carateres
• O número do quarto é único e deve apenas possuir carateres numéricos
• Em Booking a data de partida não pode ser anterior à data de chegada
• Testar todas as possíveis situações de conflito, método conflict da classe Booking
• Testar método hasVacancy de Hotel para os casos em que não há disponibilidade

O conjunto de testes a efetuar no módulo broker deve considerar todas as situações de argumentos inconsistentes e ainda as restrições abaixo. Nas situações de erro é lançada uma BrokerException:

• Testar a construção de objetos Adventure, em particular que as datas, idade e valor são consistentes com o resto das funcionalidades

Cada grupo deve-se dividir em sub-grupos de 3 alunos, em que cada um deles, trabalha num módulo. O sub-grupo que trabalhar no módulo bank deverá também trabalhar no módulo broker. É obrigatório indicar no README.md quais os elementos que trabalham em cada um dos módulos, indicando o número de aluno, o nome e o username no GitHub.

Para a entrega deverão colocar uma tag no repositório git remoto. Para isso devem após o último commit colocar a tag no repositório local fazendo, git tag ADVENTURE_1, e então fazer git push origin --tags. Esta tag deve ter uma data anterior à data limite de entrega, dia 19 de Março pelas 20:00.

Durante os laboratórios, os alunos dos grupos serão avaliados com base no trabalho desenvolvido durante cada uma das semanas. Para isso é necessária a criação de um sprint no GitHub, usando a interface de Project, em que cada tarefa deve ser representada por um note. No início do sprint é necessário criar uma coluna chamada backlog, onde são colocadas todas as tarefas a realizar e a definir numa reunião do grupo. A execução do projeto dividida em semanas, sendo cada uma delas representada por uma coluna (week1, week2, ...). Cada aluno que vá realizar uma tarefa move o respetivo note da coluna de backlog para a coluna da semana, e indica o seu nome fazendo Edit note. Quando a tarefa for terminada deve ser também incluído no note o link para o commit com o código de resolução da tarefa. Cada commit deve estar associado a uma única tarefa.