Concordo com vc, eu uso TDD em casos específicos de regras de negócio, pois s... · tuboi

Concordo com vc, eu uso TDD em casos específicos de regras de negócio, pois são eles q precisam dos parametros primeiro antes de como deve funcionar por dentro, afinal em grande parte das regras de negócio nós sabemos o q precisamos, só precisamos colocar para manipular ele, e por isso acho legal usar TDD nesses momentos. E o legal q dá pra usar IA nessa parte, pois se vc criar os testes antes, o código q gerar com a IA tem q estar de acordo com o teste. Claro q imagino q vc saiba disso, só quis comentar isso pq vc não citou, eheheh.

Eu sou dev flutter, antes eu fazia testes até pra widgets, só q ficava um gargalo na manutenção, e ela q mais atrapalhava do q ajudava, pois diferente de uma regra de negócio q precisa ser consiso com 100% de certeza, eu não preciso dizer se um componente precisa ter cor vermelha ou azul ou tamanho x ou y, pois isso é algo q muda constantemente e dá pra mitigar partes do problema padronizando designs.

Ai no meu código, eu tenho normalmente testes de unidade para as regras de negócio e testes e2e para ver se as páginas estão ligadas uma com as outras corretamente, ações dos componentes estão tudo em ordem, e outras coisas q tem mais relacionadas a ação e reação visual. Para APIs externas eu uso interface para melhor controle do q necessito e facilita eu trocar de API se aquela antiga não serve mais, sem precisar dar aquela super refatoração q normalmente acontece qndo ligamos a API direto no código.

O ponto da IA com testes primeiro é exato. Quando você escreve o teste antes, está especificando o contrato. A IA vira só um gerador de implementação que tem que satisfazer a spec, não inventar comportamento. Funciona bem na prática.

Sobre widgets no Flutter, concordo totalmente. Testar cor e tamanho é testar detalhe de CSS, basicamente. Muda constantemente e não representa comportamento real. O fluxo que importa é: botão clicou, página navegou, dado apareceu. Isso o e2e pega sem criar gargalo de manutenção.

A separação que você fez é o setup que faz sentido: unit para regras de negócio, e2e para fluxos visuais, interfaces para isolar APIs externas. Chega no mesmo lugar que o TDD prega, mas sem a rigidez de aplicar em tudo.