Objetivo:
Completar a cobertura de testes unitários e de integração do busController, garantindo que todos os fluxos e cenários relevantes do método getRoutes (e métodos auxiliares) sejam devidamente validados.
Descrição da Atividade
Desenvolver testes automatizados adicionais para o controller busController, com foco em cobrir os fluxos válidos e de erro que ainda não foram contemplados.
As dependências externas (use cases e data sources) devem ser mockadas, permitindo simular respostas esperadas e falhas controladas sem necessidade de conexões reais com banco de dados ou APIs externas.
Cenários de Teste a Implementar
Erro — cidades ausentes
Erro — IDs de cidade fora do intervalo permitido
Erro — CID inválido
Erro — cidades inexistentes no banco
Sucesso — rota encontrada
Erro interno — exceção inesperada
Testar comportamento de saveRouteSearch
-
Garantir que o método chama corretamente routeSearchDataSource.create para cada rota e CID.
Sugestão: Testar isoladamente com mocks do routeSearchDataSource e verificar se a função é chamada o número esperado de vezes.
Testar getPrimaryCid
- Quando
cid for um número → deve retornar o próprio valor.
- Quando
cid for um array → deve chamar getPrimaryAdaption.execute e retornar o resultado mockado.
- Quando ocorrer erro em
getPrimaryAdaption → deve retornar o primeiro valor do array.
Testar checkRoutesAccessibility
Critérios de Aceitação
- Mocks configurados corretamente para simular os use cases e datasources.
- Todos os mocks devem ser limpos após cada teste.
Objetivo:
Completar a cobertura de testes unitários e de integração do
busController, garantindo que todos os fluxos e cenários relevantes do métodogetRoutes(e métodos auxiliares) sejam devidamente validados.Descrição da Atividade
Desenvolver testes automatizados adicionais para o controller
busController, com foco em cobrir os fluxos válidos e de erro que ainda não foram contemplados.As dependências externas (use cases e data sources) devem ser mockadas, permitindo simular respostas esperadas e falhas controladas sem necessidade de conexões reais com banco de dados ou APIs externas.
Cenários de Teste a Implementar
Erro — cidades ausentes
Quando
originCityIdoudestinationCityIdnão forem enviados no corpo da requisição.Esperado:
400com{ erro: "Cidade de origem ou destino inválidos" }.Erro — IDs de cidade fora do intervalo permitido
Quando
originCityIdoudestinationCityIdforem menores que1ou maiores que134.Esperado:
400com{ erro: "Cidade de origem ou destino inválidos" }.Erro — CID inválido
cidfor:Um array vazio;
Um número menor ou igual a
0;Não enviado no corpo.
Esperado:
Retornar
400com{ erro: "CID inválido" }.Erro — cidades inexistentes no banco
Quando
getCityByIdUseCase.execute()retornarnullpara uma das cidades.Esperado:
400com{ erro: "Rota não encontrada para as cidades informadas" }.Sucesso — rota encontrada
Quando todos os parâmetros forem válidos e os use cases retornarem dados simulados.
Esperado:
200com objeto contendo:Erro interno — exceção inesperada
Quando qualquer use case lançar um erro não tratado.
Esperado:
500com{ erro: "Ocorreu um erro ao obter a linha informada" }.Testar comportamento de
saveRouteSearchGarantir que o método chama corretamente
routeSearchDataSource.createpara cada rota e CID.Sugestão: Testar isoladamente com mocks do
routeSearchDataSourcee verificar se a função é chamada o número esperado de vezes.Testar
getPrimaryCidcidfor um número → deve retornar o próprio valor.cidfor um array → deve chamargetPrimaryAdaption.executee retornar o resultado mockado.getPrimaryAdaption→ deve retornar o primeiro valor do array.Testar
checkRoutesAccessibilityMockar
verifyAccessibilityUseCase.executee garantir que é chamado para cada linha.Esperado: cada
linedeve receber um campovehicledefinido pelo mock.Critérios de Aceitação