Configuration: add logic to find boleto config

[alinemarjorie]

Este PR visa tirar algumas responsabilidades do boleto-processor do gateway e inserir uma nova lógica ao superbowleto.

Segue as etapas que foram adicionadas ao chegar uma requisição:

• verificar se a requisição chegou com boleto.rules preenchido, se sim deve-se considerar a carteira de acordo com a regra escolhida. (isso atualmente é feito no boleto-processor, mas mudamos para o superbowleto)
• caso não tenha boleto.rules devemos buscar as configurações de registro daquela company na model de Configurations, e se não encontrar, usar a configuração default pagarme que foi adicionada como uma seed para ser usada nos testes.
• para facilitar a virada para essa nova lógica, consideramos também que se não tiver uma configuração default, permanecem as informações que foram enviadas na requisição. Porém isso é apenas para facilitar por enquanto, pois no futuro vamos parar de receber essas informações do gateway e buscar apenas na tabela de Configurations.

Pontos de atenção:

• para conseguir resgatar as configurações da company, precisamos passar a enviar o company.id e também o campo de boleto.rules do gateway para o Superbowleto.
• alterei os testes de integração para se adaptarem a lógica nova de configurações. Os testes do bradesco não foram alterados, pois como a configuração default é Bradesco, quis garantir que esse comportamento também estava funcionando.

peace :peace_symbol:

relates to https://mundipagg.atlassian.net/browse/PGHOST-25

[jeanaugustoos]

Atualmente, bradesco. Depois, shopfacil

[vlopes]

Queria fazer uma ressalva sobre a delecao de itens nos testes (eu to sem embasamento no momento entao e so a minha opniao :smile: ). Eu nao acho legal a gente deletar as coisas apos cada teste porque isso pode acabar causando uma falsa sensacao de que os testes passaram quando na realidade eles podem quebrar. Pensando em um exemplo rapido:

• Voce cria um model num primeiro teste e faz uma query p validar se consegue recuperar esse model de acordo com algum parametro e da tudo certo.
• Apos o sucesso do primeiro teste voce apaga ese model.
• Num segundo caso de teste voce cria um segundo registro do mesmo model e executa uma query para ver se consegue recuperar esse model.
• Como o banco de dados esta apenas com o registro que voce acabou de criar o teste passa e da a falsa seguranca de que a funcionalidade esta de acordo com o que queriamos, quando na verdade se tivessemos mais registros essa query porderia se comportar de uma forma diferente.

Eu vi que alguns testes ja faziam isso antes das alteracoes desse PR, mas acho que e um ponto importante pra gente ficar de olho :eyes: .

[alinemarjorie]

Queria fazer uma ressalva sobre a delecao de itens nos testes (eu to sem embasamento no momento entao e so a minha opniao ).

Boa, Vini! Eu optei pela limpeza do dados por ser uma boa prática, pois um teste nao deveria impactar em outro, dado isso é interessante resetarmos o banco para garantirmos que nao teremos side effects. (minhas palavras aqui, mentira são as do Jean kkkk) Mas além disso, eu estou apagando depois de cada teste, por companyId, para não deletar a seed, pq qdo estava só apagando tudo depois do arquivo, deletava a seed com o default e quebrava os outros testes.