Primeira Entrega
As três funcionalidades são apresentadas de seguida. Cada subgrupo de 2 alunos fica responsável por uma das funcionalidades.
1 - Concorrer a Actividade
Objectivo: Implementar o processo de candidatura de um voluntário a uma atividade.
Modelo de Domínio
Em que o atributo motivation contém informação enviada pelo candidato e a enrollmentDateTime é criada automaticamente no momento da candidatura no construtor de Enrollment.
Funcionalidades
Serão implementadas apenas as funcionalidades:
Um voluntário candidata-se a uma atividade;
Um membro da instituição obtém a lista de todas as candidaturas a uma atividade.
Invariantes
Os seguintes invariantes de domínio devem ser implementados e testados:
Ao concorrer o voluntário deve fornecer uma motivação com pelo menos 10 caracteres;
Um voluntário apenas pode concorrer uma vez a uma atividade;
O voluntário não pode concorrer depois do fecho do período de candidatura.
As seguintes condições de acesso devem ser implementadas e testadas:
Apenas um voluntário pode concorrer a uma atividade;
Apenas o membro da instituição da atividade pode obter a lista das suas candidaturas.
Testes
Devem ser realizados os seguintes testes considerando que se pretende obter a máxima cobertura e legibilidade dos testes.
Testes de Domínio
A classe de domínio deve ser testada isoladamente, usando mocks. Estes testes devem assegurar que após a criação os invariantes de domínio se verificam. O construtor tem a seguinte assinatura:
public Enrollment(Activity activity, Volunteer volunteer, EnrollmentDto enrollmentDto)
Os testes de domínio consideram que activity e volunteer contêm valores válidos.
Testes de Serviço
Devem ser testados os serviços:
public List<EnrollmentDto> getEnrollmentsByActivity(Integer activityId)
public EnrollmentDto createEnrollment(Integer userId, Integer activityId, EnrollmentDto enrollmentDto)
Nestes testes deve ser verificado que o serviço devolve os valores corretos. Também deve ser testado que os valores de entrada são válidos: existe um voluntário associado a userId, uma atividade associada a activityId e um object enrollmentDto.
Estes testes são de componente.
Testes de Serviço Web
Devem ser testados os serviços web:
public List<EnrollmentDto> getActivityEnrollments(@PathVariable Integer activityId)
public EnrollmentDto createEnrollment(
Principal principal,
@PathVariable Integer activityId,
@Valid @RequestBody EnrollmentDto enrollmentDto)
Nestes testes deve ser verificado que o serviço devolve os valores corretos e que os resultados ficam na base de dados. Adicionalmente devem ser efetuados testes para verificar as condições de acesso.
Estes testes são de componente.
2 - Selecionar Participantes
Objectivo: Selecionar um voluntário para participar numa atividade.
Modelo de Domínio
Em que rating é dado por um membro da instituição da atividade, aquando da criação da participação, ou mais tarde, e acceptanceDate é criada automaticamente no momento da criação da participação no construtor de Participation.
Funcionalidades
Serão implementadas apenas as funcionalidades:
Um membro da instituição associa um voluntário como participante de uma atividade, em que a criação pode conter o valor da avaliação;
Um membro da instituição obtém a lista de todas as participações numa atividade.
Invariantes
Os seguintes invariantes de domínio devem ser implementados e testados:
O número total de participantes é menor ou igual o número limite de participantes da atividade;
Um voluntário apenas pode participar uma vez na atividade;
O voluntário apenas pode ser colocado como participante da atividade depois do fim do período de candidatura;
As seguintes condições de acesso devem ser implementadas e testadas:
Apenas um membro da instituição pode associar um participante à atividade;
Apenas o membro da instituição da atividade pode obter a lista dos participantes numa atividade.
Testes
Devem ser realizados os seguintes testes considerando que se pretende obter a máxima cobertura e legibilidade dos testes.
Testes de Domínio
A classe de domínio deve ser testada isoladamente, usando mocks. Estes testes devem assegurar que após a criação os invariantes de domínio se verificam. O construtor tem a seguinte assinatura:
public Participation(Activity activity, Volunteer volunteer, ParticipationDto participationDto)
Os testes de domínio consideram que activity e volunteer contêm valores válidos.
Testes de Serviço
Deve ser testados os serviços:
public List<ParticipationDto> getParticipationsByActivity(Integer activityId)
public ParticipationDto createParticipation(Integer activityId, ParticipationDto participationDto)
Nestes testes deve ser verificado que o serviço devolve os valores corretos. Também deve ser testado que os valores de entrada são válidos: existe um voluntário associado a volunteerId (que está definido em participationDto), uma actividade associada a activityId e um objeto participationDto.
Estes testes são de componente.
Testes de Serviço Web
Devem ser testados os serviços web:
public List<ParticipationDto> getActivityParticipations(@PathVariable Integer activityId)
public ParticipationDto createParticipation(@PathVariable Integer activityId,
@Valid @RequestBody ParticipationDto participationDto)
Nestes testes deve ser verificado que o serviço devolve os valores corretos e que os resultados ficam na base de dados. Adicionalmente devem ser efetuados testes para verificar as condições de acesso.
Estes testes são de componente.
3 - Avaliar Instituição
Objectivo: Um voluntário avalia uma instituição.
Modelo de Domínio
Em que review é dado por um voluntário e reviewDate é criada automaticamente no momento da avaliação, no construtor de Assessment.
Funcionalidades
Serão implementadas apenas as funcionalidades:
Um voluntário avalia uma instituição;
Qualquer utilizador, autenticado ou não, pode obter a lista de todas as avaliações de uma instituição.
Invariantes
Os seguintes invariantes de domínio devem ser implementados e testados:
É necessária uma review com pelo menos 10 caracteres;
Um voluntário apenas pode avaliar uma vez uma instituição;
Uma instituição apenas pode ser avaliada quando tem pelo menos uma atividade concluída.
As seguintes condições de acesso devem ser implementadas e testadas:
Apenas um voluntário pode avaliar uma instituição;
Qualquer pessoa pode obter a lista de todas as avaliações de uma instituição.
Testes
Devem ser realizados os seguintes testes considerando que se pretende obter a máxima cobertura e legibilidade dos testes.
Testes de Domínio
A classe de domínio deve ser testada isoladamente, usando mocks. Estes testes devem assegurar que após a criação os invariantes de domínio se verificam. O construtor tem a seguinte assinatura:
public Assessment(Institution institution, Volunteer volunteer, AssessmentDto assessmentDto)
Os testes de domínio consideram que institution e volunteer contêm valores válidos.
Testes de Serviço
Deve ser testados os serviços:
public List<AssessmentDto> getAssessmentsByInstitution(Integer institutionId)
public AssessmentDto createAssessment(Integer userId, Integer institutionId,
AssessmentDto assessmentDto)
Nestes testes deve ser verificado que o serviço devolve os valores corretos. Também deve ser testado que os valores de entrada são válidos: existe um voluntário associado a userId, uma instituição associada a institutionId e um objeto assessmentDto.
Estes testes são de componente.
Testes de Serviço Web
Devem ser testados os serviços web:
public List<AssessmentDto> getInstitutionAssessments(@PathVariable Integer institutionId)
public AssessmentDto createAssessment(Principal principal, @PathVariable Integer institutionId,
@Valid @RequestBody AssessmentDto assessmentDto)
Nestes testes deve ser verificado que o serviço devolve os valores corretos e que os resultados ficam na base de dados. Adicionalmente devem ser efetuados testes para verificar as condições de acesso.
Estes testes são de componente.
Critérios de Avaliação
Informação adicional
Cada grupo trabalha no seu repositório privado que já contém o código disponibilizado. Cada subgrupo (de 2 alunos) deve implementar uma funcionalidade diferente. A carga de trabalho (quantidade e complexidade das tarefas) deve ser dividida de forma semelhante entre os membros de cada subgrupo. Isto será verificado pelos commits. A nota 0 (zero) será atribuída a alunos que não apresentem commits. (Ver secção Grupos e Ramos para mais informação.)
Para os testes funcionarem pode ser necessário acrescentar algumas instruções em algumas das superclasses ou em classes de configuração, e.g., SpockTest.groovy e BeanConfiguration.groovy.
Sugestões de Planeamento
Ler com atenção o enunciado
Analisar o modelo de domínio
Analisar o código fornecido como suporte
Planear:
Definir as histórias para cada uma das funcionalidades. Uma sugestão é definir as histórias do ponto de vista dos serviços web.
Decompor as histórias em tarefas de modo a haver um desenvolvimento incremental que permita validação constante.
Na maior parte dos casos, cada tarefa estará associada a um elemento do subgrupo e um commit a realizar por esse elemento (por exemplo, implementação do invariante 1). Algumas tarefas (issues) podem estar atribuídas aos dois elementos do subgrupo, mas ambos os elementos terão de realizar commits (por exemplo, podemos ter uma tarefa de criação de nova classe de domínio com commits dos dois elementos do subgrupo referentes a atributos ou partes diferentes).
Sugere-se um Board por sprint (entrega), com 6 colunas:
Spring backlog
Not started tasks
In progress tasks
Tasks done
In review stories
Accepted stories
Para o critério "Markdown file with submission summary", basta preencher o template P1.md e colocá-lo numa pasta com nome "markdown". Link para template: https://gitlab.rnl.tecnico.ulisboa.pt/-/snippets/22. Versão "raw": https://gitlab.rnl.tecnico.ulisboa.pt/-/snippets/22/raw/master/P1.md