ADVENTURE_2
Setup
Para realizar a segunda parte do projeto deve obter a nova versão do código disponibilizada em https://github.com/tecnico-softeng/reference.git. Deve portanto adicionar um novo repositório remoto:
$ git remote add reference https://github.com/tecnico-softeng/reference.git
De seguida deve assegurar-se que o código da primeira parte foi entregue através do ramo first-deliver, mudando para esse ramo:
$ git checkout first-deliver
Pode então apagar a versão atual que possui do ramo master:
$ git branch -d master
e obter a nova versão do master a partir do repositório remoto reference:
$ git fetch reference
$ git checkout -b master reference/master
Para que o ramo em origin do master fique igual ao novo deve sobrepor a nova versão:
$ git push origin master --force
Deve de seguida criar o ramo develop onde o grupo irá trabalhar na segunda parte e criar esse ramo em origin:
$ git checkout -b develop
$ git push origin develop:develop
Verifique que consegue correr os testes existentes:
$ mvn clean test
Enunciado
A segunda parte versa sobre a migração dos restantes métodos ainda implementados em JUnit e JMockit para Spock. É também necessário implementar os testes Spock para a classe TaxPaymentState do módulo broker. Devem também realizar todas as alterações necessárias para que os métodos associados a invocações remotas deixem de ser métodos estáticos.
Para além disso, deve ser acrescentada uma nova funcionalidade no comportamento da reserva de um quarto durante o processamento de uma aventura. Desta forma, verifica-se primeiro se existe um quarto já reservado no contexto de um bulk booking, e se for o caso será esse o quarto utilizado. No caso em que na obtenção da informação associada à referência de bulk booking ocorra um erro, seja um exceção de hotel ou de acesso remoto, deve proceder-se ao comportamento anterior, ou seja a reserva direta no hotel. Devem alterar a funcionalidade existente para suportar este novo comportamento reutilizando e adaptando, tanto quanto possível, o código existente. Devem também implementar, e redefinir, todos os testes necessários.
Nesta parte do projeto devem ainda colocar os badges do Travis e CodeCov no README a funcionarem para o vosso projeto, e na entrega final assegurar que não estão a ser incluídas bibliotecas desnecessárias.
A submissão dos commits ao repositório do grupo deve ser feita usando pull-requests sobre o ramo develop, e cada submissão deve ser revista e aprovada por dois (2) colegas de grupo. Informação complementar para configurar os repositórios para forçar essa metodologia de desenvolvimento pode ser obtida do seguinte link https://help.github.com/en/articles/enabling-required-reviews-for-pull-requests. No âmbito do projeto, devem proteger contra pushes directos no ramo develop, e configurar develop como o ramo default (https://help.github.com/en/articles/setting-the-default-branch).
Os grupos devem começar por reunir para identificar as tarefas, associá-las ao backlog, e definir dependências de precedência entre elas, de forma a calendarizá-las no período de 2 semanas disponíveis.
Cada elemento do grupo deve migrar um número idêntico de tarefas, e que correspondam a uma quantidade de trabalho semelhante. É obrigatório indicar no README.md para cada elemento que trabalho realizou, indicando o número de aluno, o nome e o username no GitHub.
Considerando uma duração de duas semanas para a solução do projeto, serão bonificados os alunos que tenham migrado pelo menos metade das classes de teste que lhe estão atribuídas ao fim de uma semana, ou seja até ao dia 22 de Março. Note que deve ser associada uma tarefa do github a cada classe de teste a migrar e o respetivo commit deve fechar essa tarefa (closes #n).
Para a entrega deverão fazer após o último commit:
$ git checkout develop
$ git checkout -b second-deliver
$ git tag ADVENTURE_2
$ git push origin --tags second-deliver:second-deliver
Esta tag colocada deve ter uma data anterior à data limite de entrega, dia 29 de Março pelas 17: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. Neste caso o projeto a criar deve-se chamar Sprint Two. Uma vez criado o projeto, escolhendo como template pré-definido "Kanban (automatic)", deve ser alterado o nome da coluna To Do para Backlog. Nesta coluna serão colocadas todas as tarefas a realizar, as quais serão definidas durante a reunião do grupo. Cada tarefa é criada como uma Note, contendo a descrição da tarefa a realizar, e deve ser convertida num Issue, por forma a que os commits possam ser-lhe associados. Cada aluno que vá realizar uma tarefa move o respetivo note da coluna de Backlog para a coluna In progress, e atribui-se a essa tarefa no Issue respetivo. Quando a tarefa é terminada, o commit deve ser associado ao respetivo Issue, passando este para o estado fechado. Para se associar um commit a um Issue deve colocar-se na mensagem de commit closes #n, em que n é o número do Issue. Quando o Issue é fechado, o respetivo Note é automaticamente passado da coluna In progress para a coluna Done. Cada commit deve estar associado a uma única tarefa.