Devez-vous vraiment faire le BDD / TDD dans un premier temps?

11

Même si je n'ai pas été dans un projet TDD ou BDD, ou si j'ai été dans certains qui disent qu'ils font du TDD mais sont loin de là, ce sont des choses auxquelles je pense et que j'essaie vraiment de lire autant que je peux sur.

Revenons à la question. Lorsque vous faites un BDD, vous devez d'abord écrire votre "test" et le faire échouer, non? Et puis implémentez cette fonctionnalité ou ce que vous appelez. Mais si vous prenez cela à l'extrême, cela ne pourrait-il pas être une sorte de développement descendant? Vous regardez votre interface utilisateur et vous dites: «J'aimerais avoir cette fonctionnalité / ce comportement ici». Ensuite, vous corrigez votre interface utilisateur pour implémenter cette fonctionnalité et le code qui prend en charge l'interface utilisateur. À ce stade, vous n'avez implémenté aucune logique métier ou logique d'accès aux données, vous venez de mettre en œuvre votre comportement. Ce que je vise au lieu d'écrire le test d'abord, vous écrivez d'abord votre code d'interface utilisateur. Dans certains cas, il devrait en résulter le même code pour l'accès aux données et la couche métier, car vous utilisez votre code d'interface utilisateur pour définir ce que votre entreprise doit prendre en charge.

Bien sûr, vous devez compléter cela par des tests qui sont utilisés pour vous assurer que la fonctionnalité fonctionne comme elle le devrait dans la fonctionnalité.

Des pensées?

unit-testing tdd

— Tomas Jansson
source

Les tests sous TDD sont des tests unitaires , qui pilotent directement le module, comme s'il s'agissait d'un module distinct main. Dans votre commentaire de haut en bas, vous parlez de tests fonctionnels, qui exécutent l'ensemble du programme à travers un seul main.

— Macneil

@Macneil: Je ne parle pas de test fonctionnel qui teste l'ensemble du programme, même si vous implémentez / concevez votre programme de haut en bas, vous devez toujours implémenter le test unitaire pour tout votre code public. Ce n'est pas parce que vous le faites de haut en bas que vous ne pouvez pas rendre différents calques abstraits, vous pouvez donc isoler tous les calques par lui-même.

— Tomas Jansson

1

@Macneil: Il s'agit d'une idée fausse courante. Les tests TDD ne sont pas des tests unitaires . TDD teste des fonctionnalités qui n'ont pas d'échelle définie.

— Steven A. Lowe

2

Mais il y a une échelle définie: le test doit s'exécuter rapidement en TDD. Il y a des tests qui doivent se produire qui sont également hors de portée de TDD. Globalement, TDD est un plan de développement, pas un plan de test.

— Macneil

@Macneil: "rapidement" est un terme relatif. La suite de tests de mon dernier projet s'exécute en 30 minutes environ. Il remplace 8 heures de test manuel. C'est assez "vite"!

— Steven A. Lowe

8

Vous parlez de BDD dans une perspective de haut niveau de test de votre interface utilisateur. Les tests sont un peu plus moelleux à ce niveau que plus bas dans votre code côté Javascript / serveur.

Plusieurs livres que j'ai lus sur TDD disent que vous devriez écrire du code comme si les systèmes sous-jacents existaient et en écrire juste assez pour que votre test réussisse. Vous pouvez écrire des talons sur le serveur pour réussir vos tests de comportement d'interface utilisateur. Ensuite, vous commencez à cette couture de stub et écrivez quelques tests unitaires pour votre code côté serveur et descendez jusqu'à une implémentation complète.

Je code souvent comme s'il existait des couches sous-jacentes pour réussir un test de haut niveau, on a l'impression de descendre dans un terrier de lapin et d'extraire de nombreuses autres classes pour satisfaire le test de haut niveau, puis d'écrire des tests pour ces niveaux inférieurs. Comme vous l'avez déjà reconnu, cela vous aide à rester concentré en commençant par des tests de niveau supérieur.

Comme tout programmeur chevronné le sait, le développement logiciel comporte de nombreuses couches. J'ai tendance à travailler plus bas que l'interface utilisateur et à penser aux données ou au comportement dont mon interface utilisateur a besoin depuis le serveur et à commencer par là (peut-être parce que je ne fais pas beaucoup de travail sur l'interface utilisateur de nos jours).

Si je suis vraiment honnête, extraire une classe des couches sous-jacentes signifie que je ne fais pas de test en premier, mais ... dans quelques minutes ou parfois des heures, je ferai un test pour ce code. Cela me semble toujours bénéfique car j'aide à voir où vous pourriez avoir besoin de fournir des dépendances à une classe et d'honorer le principe de responsabilité unique - si c'est difficile à tester, vous en faites trop au même endroit, etc.

— Greg K
source

Je pense que tu as raison. Cela m'est arrivé quand j'ai essayé ruby sur rails cet été, là, ils ont un test bdd qui pilote l'interface utilisateur qui pilote plus tard la mise en œuvre des classes sous-jacentes.

— Tomas Jansson

17

Oui! Sinon, vous obtenez des tests axés sur le développement .

De façon réaliste, cependant, il y a des problèmes qui sont difficiles à aborder en utilisant le TDD "pur". Vous pourriez être plus productif en écrivant du code de production découvert à l'avance et en le couvrant avec des tests plus tard (et en apprenant comment aborder des problèmes similaires avec TDD à l'avenir). Regardez cette technique , que son auteur a appelée rinse-and-repeat TDD à défaut d'un meilleur terme.

— azheglov
source

3

La première ligne est géniale.

— EpsilonVector

Par rapport au TDD, c'est vrai, mais faire les choses de haut en bas devrait s'aligner assez bien avec le BDD, non? Je regarde l'interface graphique et spécifie le comportement que je veux, bien sûr, je n'écris pas le "comportement-test" tout de suite, mais j'ai spécifié le comportement via l'interface utilisateur avant de l'implémenter.

— Tomas Jansson

15

Si vous n'écrivez pas d'abord vos tests, vous ne pilotez pas le développement à travers vos tests. Ergo, vous ne faites pas de développement piloté par les tests!

— Frank Shearar
source

Pour être juste, la question n'est-elle pas plutôt de savoir si, lors d'un BDD (et non d'un TDD), nous devrions d'abord écrire le test?

— bytedev

N'hésitez pas à remplacer "test" par "comportement". Je n'ai rien vu pour me convaincre que, au fond, il y a beaucoup de différence entre TDD et BDD. Concentrez-vous, peut-être. Mais l'idée centrale? Pas tellement.

— Frank Shearar

En désaccord avec le fait que vous ne faites pas de développement piloté par les tests. Vous ne le faites pas selon la définition du terme saisi, mais tant que vous développez des tests pour votre code, votre code est définitivement piloté par les tests, quel que soit le moment où vous les écrivez.

— alternative

TDD signifie spécifiquement écrire des tests avant le code. Si vous n'aimez pas cela, prenez-le avec Kent Beck, qui a inventé le terme. L'écriture de tests après votre code peut conduire votre code dans une certaine mesure, mais vous pouvez toujours vous faire croire que vous conduisez votre conception de code à travers des tests lorsque vous ne l'êtes pas. Et il est plus difficile d'écrire ces tests, car vous devez souvent modifier du code non testé . Vu trop souvent pour le mentionner.

— Frank Shearar

@FrankShearar J'ai reconnu que ce n'est pas TDD selon ce que Kent Beck a dit, mais franchement je ne me soucie pas de ce qu'une personne au hasard a dit. Il est parfaitement possible de conduire la conception de code à travers des tests sans avoir à écrire les tests au préalable.

— alternative

4

Si vous voulez travailler de cette façon, allez-y. Mais ce n'est pas un développement piloté par les tests.

— Don Roby
source

3

Ce que vous décrivez ressemble beaucoup à l' approche Front-Ahead Design . Malheureusement, Front-Ahead Design est le coup satirique d'Alex Papadimoulis face aux méthodes agiles.

— user281377
source

Je me demandais si vous connaissez des articles qui ripostent au FAD, démystifiant son coup satirique?

— CL22

3

Personnellement, je pense qu'il est essentiel de penser aux tests pendant la phase de conception. C'est vraiment génial d'avoir une implémentation fonctionnelle, mais la seule façon d'être sûr d'avoir un produit fonctionnel est de l'avoir testé pièce par pièce. La façon de couvrir cela est par une combinaison de tests unitaires et d'une équipe qualifiée d'AQ travaillant en partenariat.

Maintenant, la façon dont vous installez cette dicipline dans votre équipe dépend de vous. TDD est l'une de ces stratégies - et celle qui a sa place, et il existe de nombreuses autres variantes. Cependant, TDD n'est pas particulièrement adapté au développement de la mise en page de l'interface utilisateur.

— Michael Shaw
source