Testez votre code comme quelqu'un qui l'utiliserait après avoir lu la documentation. Ne testez rien en vous basant sur les connaissances que vous avez parce que vous avez écrit ou lu le code. Vous voulez vous assurer que votre code se comporte comme suit : comme prévu.
Dans le meilleur des cas, vous devriez pouvoir utiliser vos tests comme exemples, les doctests en Python sont un bon exemple pour cela.
Si vous suivez ces directives, la modification de la mise en œuvre ne devrait pas poser de problème.
De plus, d'après mon expérience, il est bon de tester chaque "couche" de votre application. Vous aurez des unités atomiques, qui en elles-mêmes n'ont pas de dépendances et vous aurez des unités qui dépendent d'autres unités jusqu'à ce que vous arriviez finalement à l'application qui en elle-même est une unité.
Vous devez tester chaque couche, ne vous fiez pas au fait qu'en testant l'unité A, vous testez également l'unité B dont dépend l'unité A (la règle s'applique également à l'héritage.) Cela aussi doit être traité comme un détail de mise en œuvre, même si vous avez l'impression de vous répéter.
Gardez à l'esprit qu'une fois écrits, les tests ont peu de chances d'être modifiés, alors que le code qu'ils testent changera presque certainement.
Dans la pratique, il y a aussi le problème de l'IO et du monde extérieur, il faut donc utiliser des interfaces pour pouvoir créer des mocks si nécessaire.
Dans les langages plus dynamiques, ce n'est pas vraiment un problème. Ici, vous pouvez utiliser le typage de canard, l'héritage multiple et les mixins pour composer les cas de test. Si vous commencez à ne pas aimer l'héritage en général, vous faites probablement bien les choses.
