O que você descreve pode não ser tão ruim, mas um indicador de problemas mais profundos que seus testes descobrem
À medida que o sistema muda, nos vemos gastando mais tempo consertando testes quebrados. Temos testes unitários, de integração e funcionais.
Se você pudesse alterar seu código e seus testes não fossem interrompidos, isso seria suspeito para mim. A diferença entre uma mudança legítima e um bug é apenas o fato de ser solicitada, e o que é solicitado é (TDD assumido) definido pelos seus testes.
os dados foram codificados.
Dados codificados em testes são uma coisa boa. Os testes funcionam como falsificações, não como provas. Se houver muito cálculo, seus testes podem ser tautologias. Por exemplo:
assert sum([1,2,3]) == 6
assert sum([1,2,3]) == 1 + 2 + 3
assert sum([1,2,3]) == reduce(operator.add, [1,2,3])
Quanto maior a abstração, mais você se aproxima do algoritmo e, com isso, mais perto de comparar a implementação acutal a si mesma.
muito pouca reutilização de código
A melhor reutilização de código nos testes é imho 'Checks', como nas jUnits assertThat
, porque eles mantêm os testes simples. Além disso, se os testes puderem ser refatorados para compartilhar código, o código real testado provavelmente também pode ser , reduzindo assim os testes àqueles que testam a base refatorada.