Grupo 6 _ Sprint 3

[GustavoMacCar]

Grupo 6 _ Sprint 3

O intuito dessa sprint era garantir que os métodos presentes no código estivessem dentro das métricas aceitáveis para os parâmetros de complexidade ciclomática, ABC score e garantir uma taxa de cobertura > 90% para os testes Rspec. Além disso, também foi feita a documentação dos métodos e models do código, assim como a refatoração de funcionalidades que não estavam implementadas de forma adequada na sprint 2.

Funcionalidades refatoradas

Concernente à refatoração de funcionalidades (não por uma questão das métricas avaliadas nessa sprint, mas por uma questão do funcionamento propriamente dito), podemos falar sobre a implementação das notificações:
As notificações foram implementadas de uma forma um pouco diferente do esquema de banco de dados sugerido pelo monitor no início da realização deste projeto. Não foi implementada a classe UserNotifications, de modo que cada usuário pode possuir muitas notificações e cada notificação pode ser visiível para mais de um usuário. As notificações foram implementadas de forma parecida com as notícias. No campo que representa o grupo de interesse, é definido para quais usuários aquela notificação será visível, diferentemente das notícias, que são sempre visíveis para todos os usuários.
Por exemplo: quando uma notificação é adicionada e tem como grupo de interesse os professores, somente professores e administradores conseguirão ver aquela notificação. Administradores conseguem ver todas notificações.
Outras refatorações concernentes a funcionalidades foram com relação à segurança, por exemplo: impedir que um usuário não logado possa visualizar as páginas do site por meio da url e impedir que um usuário que não é um administrador possa acessar as páginas de edição e criação de objetos por meio da url. Foi implementada a funcionalidade de busca por fonte, que não havia sido implementada na sprint 2.

Complexidade ciclomática < 10 por método

Foi realizada a instalação da gema saikuro e os comados foram executados conforme as instruções do repositório. Para esta etapa, nenhum método precisou ser refatorado, pois todos já apresentavam complexidade ciclomática menor que 10. Os arquivos gerados podem ser encontrados na pasta saikuro_output.

ABC Score < 20 por método

Inicialmente foi utilizada a gema rubycritic, conforme a especificação do trabalho. No entanto, essa gema não se mostrou muito adequada para a cobertura do ABC score, visto que não mostrava tal métrica para cada um dos métodos e sim apenas uma média de complexidade/método para cada um dos módulos. Foi utilizada então a gema flog. Por meio dela é possível observar o ABC score de cada um dos métodos no terminal com o comando flog -am app. Nessa etapa foi necessário refatorar o método index da controladora de notificações, pois, caso fosse feita uma verificação para checar se o usuário era um administrador, a complexidade seria maior que 20. O método foi portanto refatorado e todos os métodos ficaram com complexidade menor que 20.
Os arquivos gerados pelo rubycritic podem ser encontrados em tmp/rubycritic

Cobertura dos testes RSpec > 90%

A gema foi instalada e executada conforme as instruções do repositório.
Inicialmente, a cobertura dos testes estava assim:

Arquivo	Taxa de cobertura
app/controllers/informations_controller.rb	41%
spec/controllers/InfoSourceFilter_spec.rb	50%
app/controllers/sources_controller.rb	60,71%
app/controllers/application_controller.rb	80%
app/models/information.rb	80%
spec/rails_helper.rb	86,67%

Os arquivos omitidos na tabela estavam com 100% de cobertura.
Depois foram escritos novos testes e a cobertura de todos arquivos está em 100%, exceto para o rails_helper, que está em 91,67%.
Os arquivos gerados pelo simplecov podem ser encontrados na pasta coverage. Vale dizer que na execução desta etapa foram instaladas as gemas FacotryBot e database_cleaner-active_record para simular o login de usuários nos testes e a limpeza dos bancos de dados de testes após o fim da execução da suite de testes. É válido dizer que cada teste pode executar ações além das descritas. Isso foi feito para garantir uma maior independência entre os testes. A descrição de cada teste deve ser suficiente para proporcionar um bom entendimento de seu funcionamento.

Happy Path e Sad Path nas features do Cucumber/Rspec

Os teste cucumber já cobriam happy path e sad path na sprint 1. Foram adicionados sad path nos testes Rspec que já haviam sido implementados, assim como nos novos testes.

Documentação do código com RDoc

A gema foi instalada e executada conforme a documentação. Foram escritos comentários para cada um dos métodos criados, conforme a especificação do trabalho. A documentação pode ser encontrada na pasta doc.

Integrantes

1. Fábio Oliveira Guimarães - 19/0099330
2. Gustavo Costa de Souza - 15/0128576
3. Gustavo Macedo de Carvalho - 17/0058867
4. Ricardo Silva Moreira - 16/0143756
5. Rodrigo Bornéo de Oliveira - 14/0031065

Papéis

• Scrum Master: Gustavo Macedo de Carvalho - 17/0058867
• Product Owner: Rodrigo Bornéo de Oliveira - 14/0031065

Funcionalidades desenvolvidas

• Gustavo Macedo de Carvalho

1. Funcionalidades de segurança
2. Adição de novos testes referentes à issue #14
3. Adição de novos testes referentes a todas outras issues
4. Funcionalidades das notificações
5. Documentação

• Rodrigo Bornéo de Oliveira

1. Adição de novos testes referentes à issue #15
2. Funcionalidades de segurança

• Gustavo Costa de Souza

1. Adição de novos testes referentes à issue #16
2. Funcionalidades de segurança

• Ricardo Silva Moreira

3. Adição de novos testes referentes à issue #17
4. Funcionalidade de busca por fonte

• Fábio Oliveira Guimarães

1. Adição de novos testes referentes à issue #18
2. Funcionalidades das notificações