Un retentissant OUI avec TDD (et à quelques exceptions près)
Bien controversé, mais je dirais que quiconque répond «non» à cette question manque un concept fondamental du TDD.
Pour moi, la réponse est un oui retentissant si vous suivez TDD. Si vous ne l'êtes pas, non est une réponse plausible.
La DDD en TDD
TDD est souvent cité comme ayant les principaux avantages.
- La défense
- S'assurer que le code peut changer mais pas son comportement .
- Cela permet la pratique toujours aussi importante de la refactorisation .
- Vous gagnez ce TDD ou non.
- Conception
- Vous spécifiez ce que doit faire quelque chose, comment il doit se comporter avant de le mettre en œuvre .
- Cela signifie souvent des décisions de mise en œuvre plus éclairées .
- Documentation
- La suite de tests doit servir de documentation de spécification (exigences).
- L'utilisation de tests à cette fin signifie que la documentation et la mise en œuvre sont toujours dans un état cohérent - un changement de l'un signifie un changement de l'autre. Comparez avec les exigences de conservation et la conception sur un document Word séparé.
Séparer la responsabilité de la mise en œuvre
En tant que programmeurs, il est terriblement tentant de considérer les attributs comme quelque chose d’important et d’attirer et de définir une sorte de surcharge.
Mais les attributs sont un détail d'implémentation, tandis que les setters et les getters sont l'interface contractuelle qui permet aux programmes de fonctionner.
Il est bien plus important d’épeler qu’un objet doit:
Autoriser ses clients à changer d'état
et
Autoriser ses clients à interroger son état
puis comment cet état est réellement stocké (pour lequel un attribut est le plus commun, mais pas le seul moyen).
Un test tel que
(The Painter class) should store the provided colour
est important pour la partie documentation de TDD.
Le fait que la mise en œuvre éventuelle soit triviale (attribut) et ne comporte aucun avantage en termes de défense devrait vous être inconnu lorsque vous écrivez le test.
Le manque d'ingénierie aller-retour ...
L'un des problèmes majeurs du monde du développement de systèmes est le manque d' ingénierie aller-retour 1 - le processus de développement d'un système est fragmenté en sous-processus disjoints dont les artefacts (documentation, code) sont souvent incohérents.
1 Brodie, Michael L. "John Mylopoulos: coudre des graines de modélisation conceptuelle." Modélisation conceptuelle: fondements et applications. Springer Berlin Heidelberg, 2009. 1-9.
... et comment TDD le résout
C’est la partie documentation de TDD qui garantit la cohérence des spécifications du système et de son code.
Concevoir d'abord, mettre en œuvre plus tard
Dans TDD, nous écrivons d’abord le test d’acceptation ayant échoué, puis nous écrivons le code qui les laisse passer.
Au sein du BDD de niveau supérieur, nous écrivons d’abord des scénarios, puis nous les faisons passer.
Pourquoi devriez-vous exclure les setters et les getter?
En théorie, au sein de TDD, il est parfaitement possible à une personne d’écrire le test et à une autre d’implémenter le code qui le fait passer.
Alors demandez-vous:
La personne qui écrit les tests pour une classe doit-elle mentionner les accesseurs et les passeurs.
Comme les getters et les setters sont une interface publique avec une classe, la réponse est évidemment oui , sinon il n'y aura aucun moyen de définir ou d'interroger l'état d'un objet.
De toute évidence, si vous écrivez le code en premier, la réponse risque de ne pas être aussi claire.
Exceptions
Il existe des exceptions évidentes à cette règle - des fonctions qui sont détaillées dans la mise en œuvre et qui ne font manifestement pas partie de la conception du système.
Par exemple, a la méthode locale 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
Ou la fonction privée square()ici:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Ou toute autre fonction ne faisant pas partie d'une publicinterface nécessitant une orthographe dans la conception du composant système.