Jumelage adversaire / naïf avec TDD: quelle est son efficacité?

Question

Un de mes amis m'expliquait comment ils établissaient une association ping-pong avec TDD sur son lieu de travail et il a ajouté qu'ils prenaient un traitement "accusatoire". approche. Autrement dit, lorsque la personne qui rédige le test remet le clavier à l’implémenteur, celui-ci essaie de faire le plus simple possible (et parfois une erreur) de faire passer le test.

Par exemple, s'ils testent une méthode GetName () et que le test vérifie "Sally", l'implémentation de la méthode GetName sera simplement:

public string GetName(){
    return "Sally";
}

Qui réussirait bien sûr le test (naïvement).

Il explique que cela aide à éliminer les tests naïfs qui vérifient des valeurs prédéfinies spécifiques plutôt que de tester le comportement réel ou l'état attendu des composants. Cela aide également à créer plus de tests et finalement une meilleure conception et moins de bugs.

Cela sonnait bien, mais lors d’une courte séance avec lui, il a semblé qu’il avait fallu beaucoup plus de temps pour réussir une seule ronde de tests qu’autre chose et je ne pensais pas que nous aurions gagné beaucoup de valeur supplémentaire.

Utilisez-vous cette approche, et si oui, l'avez-vous vue payante?

Answer 1

Il est basé sur la personnalité de l'équipe. Chaque équipe a une personnalité qui est la somme de ses membres. Vous devez faire attention à ne pas pratiquer des implémentations passives-agressives faites avec un air de supériorité. Certains développeurs sont frustrés par les implémentations telles que

  

renvoyer " Sally " ;;

Cette frustration conduira à une équipe infructueuse. J'étais parmi les frustrés et je ne l'ai pas vu porter ses fruits. Je pense qu'une meilleure approche consiste à mieux communiquer oralement en faisant des suggestions sur la manière de mieux mettre en œuvre un test.

Answer 2

Cela peut être très efficace.

Cela vous oblige à réfléchir davantage au test que vous devez écrire pour que l'autre programmeur écrive la fonctionnalité dont vous avez besoin.

Vous construisez le code pièce par pièce en passant fréquemment le clavier

Cela peut être assez fatiguant et prend beaucoup de temps, mais j’ai trouvé que c’est rare que j’ai dû revenir pour corriger un bogue dans un code écrit de cette façon

Answer 3

J'ai utilisé cette approche. Cela ne fonctionne pas avec toutes les paires; certaines personnes sont simplement naturellement résistantes et ne lui donneront pas une chance honnête. Cependant, cela vous aide à utiliser correctement TDD et XP. Vous voulez essayer d'ajouter des fonctionnalités à votre base de code lentement. Vous ne voulez pas écrire un test monolithique énorme qui nécessitera beaucoup de code à satisfaire. Vous voulez un tas de tests simples. Vous voulez également vous assurer de passer le clavier entre vos paires régulièrement afin que les deux paires soient engagées. Avec un couplage contradictoire, vous faites les deux. De simples tests mènent à des implémentations simples, le code est construit lentement et les deux personnes sont impliquées tout au long du processus.

Answer 4

J'aime cela de temps en temps - mais n'utilisez pas ce style tout le temps. Agit comme un bon changement de rythme par moments. Je ne pense pas que j'aimerais utiliser ce style tout le temps.

J'ai trouvé utile aux débutants de savoir comment les tests peuvent guider la mise en œuvre.

Answer 5

(D'abord, les confrontations TDD devraient être amusantes. Elles devraient être une opportunité pour l'enseignement. Cela ne devrait pas être une opportunité pour les rituels de domination humaine. S'il n'y a pas de place pour un peu d'humour, quittez l'équipe Désolé, la vie est trop courte pour être gâchée dans un environnement négatif.)

Le problème ici est des tests mal nommés. Si le test ressemblait à ceci:

foo = new Thing("Sally")
assertEquals("Sally", foo.getName())

Ensuite, je parie qu'il a été nommé " testGetNameReturnsNameField ". C'est une mauvaise réputation, mais pas de façon évidente de la sorte. Le nom approprié pour ce test est " testGetNameReturnsSally ". C'est ce que ça fait. Tout autre nom vous induit dans un faux sentiment de sécurité. Donc, le test porte un mauvais nom. Le problème n'est pas le code. Le problème n'est même pas le test. Le problème est le nom du test.

Si le testeur avait nommé le test " testGetNameReturnsSally ", il aurait immédiatement été évident qu'il ne s'agissait probablement pas de tester ce que nous souhaitons.

Il est donc du devoir du responsable de la mise en œuvre de démontrer le mauvais choix du testeur. Il est également du devoir du réalisateur de n’écrire que ce que les tests leur demandent.

Tant de bugs dans la production ne se produisent pas parce que le code a fait moins que prévu, mais parce qu'il en a fait plus Oui, il y avait des tests unitaires pour tous les cas attendus, mais il n'y avait pas de tests pour tous les cas particuliers du code car le programmeur pensait que "je ferais mieux de faire cela aussi, nous aurons probablement besoin de" et puis oublié à ce sujet. C'est pourquoi TDD fonctionne mieux que test-after. C'est pourquoi nous jetons le code après un pic. Le code peut faire tout ce que vous voulez, mais il fait probablement quelque chose dont vous pensiez avoir besoin et que vous avez oublié.

Forcez le rédacteur de test à tester ce qu'il veut vraiment. N'écrivez que du code pour réussir les tests et pas plus.

RandomStringUtils est votre ami.