Je me heurte régulièrement à ce problème, et je ne sais pas comment surmonter cet obstacle. J'ai vraiment envie de commencer à apprendre et à appliquer le développement piloté par les tests (ou BDD, ou autre), mais il semble que chaque application que je fais et que je veux appliquer se limite à des trucs standard de CRUD de base de données, et je ne sais pas comment m'y prendre. Les objets ne font pratiquement rien, à part être persistés dans une base de données ; il n'y a pas de logique complexe à tester. Il y a une passerelle que je devrai éventuellement tester pour un service tiers, mais je veux d'abord terminer le cœur de l'application.
Chaque fois que j'essaie d'écrire des tests, je ne teste que des éléments de base que je ne devrais probablement pas tester en premier lieu (par exemple, les getters/setters), mais il ne semble pas que les objets aient autre chose. Je suppose que je pourrais tester la persistance mais cela ne me semble jamais correct parce que vous n'êtes pas supposé toucher une base de données, mais si vous la simulez alors vous ne testez vraiment rien parce que vous contrôlez les données qui sont renvoyées ; comme j'ai vu beaucoup d'exemples où il y a un référentiel simulé qui simule une base de données en bouclant et en créant une liste de valeurs connues, et le test vérifie que le "référentiel" peut récupérer une certaine valeur... Je ne vois pas l'intérêt d'un tel test car bien sûr le "repository" va retourner cette valeur ; c'est codé en dur dans la classe ! Eh bien, je le vois d'un point de vue purement TDD (c'est-à-dire que vous devez avoir un test disant que votre référentiel a besoin d'une méthode GetCustomerByName ou autre avant que vous puissiez écrire la méthode elle-même), mais cela ressemble à suivre un dogme sans autre raison que sa "façon de faire" - le test ne semble pas faire quelque chose d'utile en dehors de justifier une méthode.
Est-ce que je pense à ça de la mauvaise façon ?
Prenons l'exemple d'une application courante de gestion des contacts. Nous avons des contacts, et disons que nous pouvons envoyer des messages aux contacts. Nous avons donc deux entités : Contact y Message chacun avec des propriétés communes (par exemple, Prénom, Nom, Courriel pour le contact, et Objet, Corps et Date pour le message). Si aucun de ces objets n'a de comportement réel ou n'a besoin d'exécuter une quelconque logique, comment appliquer le TDD lors de la conception d'une application comme celle-ci ? Le seul but de l'application est essentiellement de récupérer une liste de contacts et de les afficher sur une page, d'afficher un formulaire pour envoyer un message, et ainsi de suite. Je ne vois aucune sorte de tests utiles ici - je pourrais penser à quelques tests mais ils seraient plutôt des tests pour le plaisir de dire "Vous voyez, j'ai des tests !" au lieu de tester réellement une sorte de logique (Bien que Ruby on Rails en fasse bon usage, je ne considère pas vraiment le test de validation comme un test "utile" parce que cela devrait être quelque chose dont le framework s'occupe pour vous).
