Appliquer TDD lorsque l’application est 100% CRUD

Je rencontre couramment ce problème et je ne sais pas comment surmonter cet obstacle. Je veux vraiment commencer à apprendre et à appliquer le développement piloté par les tests (ou BDD, ou autre), mais il semble que toutes les applications que je fais où je veux l’appliquer pour l’appliquer. Les objects ne font quasiment rien d’autre que d’être persistés dans une firebase database; 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 que le cœur de l’application soit fait en premier.

Chaque fois que j’essaie d’écrire des tests, je ne fais que tester des trucs de base que je ne devrais probablement pas tester (p.ex. getters / setters), mais il ne semble pas que les objects aient autre chose. Je suppose que je pourrais tester la persistance, mais cela ne me semble pas juste parce que vous n’êtes pas censé bash une firebase database, mais si vous l’examinez, vous ne testez rien car vous contrôlez les données qui sont crachées; comme j’ai vu beaucoup d’exemples où il existe un référentiel simulé qui simule une firebase database en faisant une boucle 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 … ne pas voir le point d’un test comme celui-ci parce que le “référentiel” va bien sûr renvoyer cette valeur; c’est codé en dur dans la classe! Eh bien, je le vois d’un sharepoint vue TDD (c.-à-d. Que vous devez avoir un test indiquant que votre référentiel a besoin d’une méthode GetCustomerByName ou autre avant d’écrire la méthode), mais cela semble suivre le chemin “- le test ne semble pas faire autre chose que de justifier une méthode.

Est-ce que je pense à cela de manière erronée?

Par exemple, faites un test de l’application de gestion des contacts d’usine. Nous avons des contacts et disons que nous pouvons envoyer des messages aux contacts. Nous avons donc deux entités: Contact et Message , chacune ayant des propriétés communes (par exemple, prénom, nom, adresse électronique pour le contact, object et corps et date du message). Si aucun de ces objects n’a de comportement réel ou n’a besoin d’exécuter une logique quelconque, alors comment appliquez-vous TDD lors de la conception d’une application comme celle-ci? Le seul but de l’application est de tirer une liste de contacts et de les afficher sur une page, d’afficher un formulaire pour envoyer un message, etc. Je ne vois aucune sorte de tests utiles ici – je pourrais penser à quelques tests mais ils seraient plutôt des tests pour dire “Voyez, j’ai des tests!” au lieu de tester un certain type de logique (bien que Ruby on Rails en fasse un bon usage, je ne considère pas vraiment que la validation des tests soit un test “utile” car le framework devrait en prendre soin)

“Le seul but de l’application est de tirer une liste de contacts”

D’accord. Testez cela. Que signifie “tirer”? Cela ressemble à “logique”.

“les afficher sur une page”

D’accord. Testez cela. Les bons affichés? Tout y est?

“afficher un formulaire pour envoyer un message”

D’accord. Testez cela. Les bons champs? Les validations des entrées fonctionnent-elles toutes?

” etc.”

D’accord. Testez cela. Est-ce que les requêtes fonctionnent? Trouver les bonnes données? Afficher les bonnes données? Valider les entrées? Produire les bons messages d’erreur pour les entrées non valides?

Je travaille actuellement sur une application CRUD pure Mais je vois beaucoup d’avantages des tests unitaires (note- je n’ai pas dit TDD)

J’écris d’abord le code et ensuite les cas de test, mais jamais trop séparés

Et je teste aussi les opérations CRUD – la persistance dans la firebase database.

Quand j’aurai fini avec la persistance – et que je passerai à la couche d’interface utilisateur – j’aurai assez confiance que ma couche de service \ persistance est bonne et je pourrai alors me concentrer sur l’interface utilisateur seule à ce moment.

Donc, à mon humble avis, les tests TDD \ Unit offrent toujours des avantages (peu importe comment vous les appelez en fonction de votre extrême sensibilité), même pour les applications CRUD. Il vous suffit de trouver la bonne stratégie pour votre application.

Utilisez simplement le bon sens … et vous irez bien.

Je pense que nous confondons TDD avec les tests unitaires.

Les tests unitaires sont des tests spécifiques qui testent des unités de comportement. Ces tests sont souvent inclus dans la version d’intégration. S.Lott a décrit quelques excellents candidats pour ces types de tests.

TDD est pour la conception. Je trouve plus souvent alors que mes tests que j’écris en utilisant TDD seront soit éliminés, soit évoluer en un test unitaire. La raison en est que lorsque je travaille sur TDD, je teste ma conception pendant que je conçois mon application, ma classe, ma méthode, mon domaine, etc.

En réponse à votre scénario, je suis d’accord avec ce que S.Lott a laissé entendre, c’est que vous avez besoin d’une suite de tests unitaires pour tester des comportements spécifiques dans votre application.

Sauter. Tout ira bien. Je suis sûr que vous avez une date limite pour vous rencontrer. (/sarcasme)

Le mois prochain, nous pouvons revenir en arrière et optimiser les requêtes en fonction des commentaires des utilisateurs. Et briser des choses que nous ne savions pas que nous n’étions pas censés briser.

Si vous pensez que le projet durera 2 semaines et ne sera jamais rouvert, le test automatisé est probablement une perte de temps. Sinon, si vous êtes intéressé à “posséder” ce code pendant quelques mois et à le faire, construisez des tests. Utilisez votre jugement pour savoir où est le plus grand risque. Pire encore, si vous envisagez de faire partie de la compagnie pendant quelques années et que vous avez d’autres coéquipiers qui jouent à tour de rôle sur différentes parties d’un système, et que vous reviendrez dans un an, construisez des tests.

Ne le faites pas trop, mais «mettez quelques broches dedans», de sorte que si les choses commencent à «bouger», vous avez des alarmes pour attirer l’attention sur des choses.

La plupart de mes tests ont été des tests de type JUnit ou batch “diff”, et un outil de type rudimentaire, j’ai écrit quelques années auparavant (scripter des choses de type regex + wget / curl). J’entends que le selenium est censé être un bon outil pour tester l’interface utilisateur des applications Web, mais ne l’a pas essayé. Quelqu’un at-il des outils disponibles pour les applications GUI locales ???

À mon avis, utiliser une application CRUD simple, c’est un peu comme pratiquer des gammes sur une guitare – vous pouvez penser que c’est ennuyeux et fastidieux de découvrir à quel point votre jeu s’améliore. En termes de développement – vous seriez susceptible d’écrire un code moins couplé – plus testable. De plus, vous êtes plus susceptible de voir les choses du sharepoint vue du consommateur de code – vous l’utiliserez réellement. Cela peut avoir beaucoup d’effets secondaires intéressants comme des API plus intuitives, une meilleure séparation des problèmes, etc. Certes, il existe des générateurs d’échafaudages capables de faire du CRUD de base et ils ont une place particulière dans le prototypage. de toutes sortes. Pourquoi ne pas vous concentrer sur le domaine principal en premier lieu, en reportant les décisions sur le framework / l’interface utilisateur / la firebase database jusqu’à ce que vous ayez une meilleure idée des fonctionnalités essentielles? TDD peut également vous aider. Dans votre exemple: Voulez-vous que les messages soient une queue ou une arborescence hiérarchique, etc.? Voulez-vous qu’ils soient chargés en temps réel? Qu’en est-il du sorting / recherche? avez-vous besoin de prendre en charge JSON ou simplement html? Il est beaucoup plus facile de voir ce genre de questions avec BDD / TDD. Si vous faites du TDD, vous pourrez peut-être tester votre logique de base sans même utiliser un framework (et attendre une minute pour le charger / exécuter)

Juste une idée…

Prenez les exigences pour le CRUD, utilisez des outils tels que watij ou watir ou AutoIt pour créer des cas de test. Commencez à créer l’interface utilisateur pour passer les cas de test. Une fois que vous avez l’interface utilisateur et que vous avez réussi peut-être un seul test, commencez à écrire la couche logique pour ce test, puis la couche db.

Pour la plupart des utilisateurs, l’interface utilisateur est le système. N’oubliez pas d’écrire des scénarios de test pour chaque nouveau calque que vous créez. Donc, au lieu de commencer à partir de la firebase database vers l’application, commencez en sens inverse.

À la fin de la journée, vous auriez probablement un ensemble de tests de régression puissant, afin de vous donner la confiance nécessaire pour effectuer le refactoring en toute sécurité.

c’est juste une idée …

Je vois ce que vous dites, mais vos modèles finiront par devenir suffisamment avancés pour nécessiter (ou être considérablement enrichis) de tests automatisés. Sinon, vous développez essentiellement un tableur que quelqu’un a déjà développé pour vous.

Puisque vous avez mentionné Rails, je dirais que faire un test standard de création / lecture / mise à jour / suppression est une bonne idée pour chaque propriété, en particulier parce que votre test devrait noter les permissions (je pense que c’est énorme). Cela garantit également que vos migrations fonctionnent comme prévu.

Je travaille actuellement sur une application CRUD. Ce que je fais à ce stade, c’est écrire des tests unitaires sur les objects de mon référentiel et vérifier que les fonctionnalités du CRUD fonctionnent comme elles le devraient. J’ai constaté que cela a insortingnsèquement testé l’unité du code de firebase database réel. Nous avons trouvé plusieurs bogues dans le code de la firebase database. Je vous suggère donc d’aller de l’avant et de continuer avec les tests unitaires. Je sais que l’application de TDD sur les applications CRUD n’est pas aussi séduisante que ce que vous pourriez lire dans les blogs ou les magazines, mais elle remplit son rôle et vous vous sentirez beaucoup mieux lorsque vous travaillerez sur une application plus complexe.

Ces jours-ci, vous ne devriez pas avoir besoin de beaucoup de code écrit à la main pour une application CRUD en dehors de l’interface utilisateur, car il existe 101 frameworks qui généreront la firebase database et le code d’access aux données.

Je voudrais donc réduire la quantité de code écrit à la main et automatiser les tests de l’interface utilisateur. Ensuite, j’utiliserais TDD des bits de logique impairs qui doivent être écrits à la main.