Au travail, l'un de mes projets consiste principalement à prendre des données transmises par un client externe et à les conserver dans une base de données. Il s'agit d'une application d'entreprise Java utilisant JPA et la plupart de nos logiques tournent autour des opérations CRUD.
La majorité de nos bogues impliquent JPA d'une manière ou d'une autre.
- Exemple 1: Si vous cliquez deux fois sur le bouton Enregistrer, JPA peut essayer d'insérer la même entité dans la base de données une deuxième fois, provoquant une violation de clé primaire.
- Exemple 2: vous récupérez une entité de la base de données, la modifiez et essayez de mettre à jour ses données. JPA peut essayer de créer une nouvelle instance au lieu de mettre à jour l'ancienne.
Souvent, la solution doit ajouter / supprimer / modifier une annotation JPA. D'autres fois, il s'agit de modifier la logique DAO.
Je ne peux pas comprendre comment obtenir la confiance dans notre code en utilisant des tests unitaires et TDD. Je ne sais pas si c'est parce que les tests unitaires et TDD sont mal adaptés, ou si j'approche mal le problème.
Les tests unitaires semblent être un mauvais ajustement car je ne peux découvrir ces problèmes qu'au moment de l'exécution et je dois déployer sur un serveur d'applications pour reproduire les problèmes. Habituellement, la base de données doit être impliquée, ce que je considère être en dehors de la définition d'un test unitaire: ce sont des tests d'intégration.
TDD semble être un mauvais ajustement car la boucle de rétroaction de déploiement + test est si lente qu'elle me rend très improductif. La boucle de rétroaction de déploiement + test prend plus de 3 minutes, et c'est juste si j'exécute les tests spécifiquement sur le code que j'écris. Pour exécuter tous les tests d'intégration prend plus de 30 minutes.
Il y a du code en dehors de ce moule et je teste toujours cela chaque fois que je le peux. Mais la majorité de nos bogues et les plus gros puits de temps impliquent toujours JPA ou la base de données.
Il y a une autre question qui est similaire , mais si je suivais les conseils, j'envelopperais la partie la plus instable de mon code (le JPA) et testerais tout sauf lui. Dans le cadre de ma question, je serais dans la même mauvaise situation. Quelle est la prochaine étape après avoir enveloppé l'APP? OMI, cette question est (peut-être) une étape pour répondre à ma question, mais pas une réponse.
unit testing != TDD)