feat: implementa leitura de eventos - #541
MariaGabriela-JR wants to merge 1 commit into
Conversation
EduTiyo
left a comment
EduTiyo
left a comment
There was a problem hiding this comment.
Revisão em duas frentes (Standards e Spec) da leitura de Eventos. A busca por id (BuscarEventoController) está correta e, inclusive, evita o bug de mapeamento de erro que peguei no PR do Jordan (#540) — separa falha de infra (500) de "não encontrado" (404), parabéns por isso. Mas a listagem entrega só o roteamento: os três pedidos centrais do spec — paginação (?limite/?pagina), os filtros já existentes em EventoFilters (tipo, capturado_de, capturado_ate) e a ordenação estável (capturado_em desc, id desc, chamada de "a parte difícil" no combinado do time) — não chegam a ser usados. Falta também cobertura de integração para as duas rotas novas.
| return new BadRequestError({ message: 'expedicaoId inválido' }) | ||
| } | ||
|
|
||
| const result = await this.listaEventosUseCase.execute({ |
There was a problem hiding this comment.
[Spec] Filtros, paginação e ordenação estável não chegam até aqui. EventoCollection.findAll já suporta tipo, capturado_de, capturado_ate e order, mas o handler só lê expedicaoId de request.params e monta { expedicao_id } — os filtros do spec ficam inalcançáveis via HTTP. Também falta ler ?limite/?pagina da query (combinado com o Jordan: "as duas listagens do módulo precisam paginar do mesmo jeito") e falta forçar order = { column: 'capturado_em', direction: 'desc' } com desempate por id, que é o ponto que o spec chama de "a parte difícil" — sem isso, duas linhas com o mesmo capturado_em podem sumir ou duplicar entre páginas assim que a paginação existir.
| interface Dependencies { | ||
| listaEventosUseCase: ListaEventosUseCase | ||
| } | ||
|
|
There was a problem hiding this comment.
[Standards] Sem cobertura de integração. Só há teste unitário com use case mockado (test/unit/application/evento/ListaEventosController.test.ts). Módulos irmãos que ganharam endpoints GET novos (fase-sucessional, vegetacao) vieram com test/integration/<modulo>/lista-*.test.ts batendo no app + banco real. test/integration/evento/evento-collection.test.ts já existe mas só testa o adapter, não a rota HTTP nova.
| this.buscarEventoPorIdUseCase = dependencies.buscarEventoPorIdUseCase | ||
| } | ||
|
|
||
| async handle(request: HttpRequest, _next: NextHandler): Promise<HttpResponse | HttpError> { |
There was a problem hiding this comment.
[Standards] Duplicated Code (smell). Este bloco de validação de id (undefined/null/''/regex) é idêntico ao de ListaEventosController.ts:22-27, só muda o nome do campo e a mensagem. Com duas ocorrências ainda não acho que compense extrair, mas vale ficar de olho se aparecer um terceiro controller.
| } | ||
|
|
||
| execute(filters: EventoFilters): Promise<Either<Error, Attributes[]>> { | ||
| return this.eventoCollection.findAll(filters) |
There was a problem hiding this comment.
[Standards] Speculative Generality (smell). execute aceita o EventoFilters inteiro, mas hoje o único chamador (ListaEventosController) nunca passa mais que expedicao_id — o restante do filtro é capacidade morta na camada HTTP até o controller ser corrigido para repassar os outros campos.
2 participants
O que foi feito
Implementados os endpoints de leitura de Eventos da API v2:
GET /api/v2/expedicoes/:expedicaoId/eventosGET /api/v2/eventos/:eventoIdImplementação
create-app.ts.EventoCollectionKnexAdapterexistente.expedicaoIdeeventoId.Testes
yarn run test:unit: 79 testes passando.yarn run tsc:check: concluído com sucesso.yarn run lint:eslint: concluído com sucesso.