développement piloté par les tests - Qui doit passer les tests?

À l'origine, il est du devoir du développeur d'écrire le test, mais j'ai remarqué que dans de nombreux cas / développeurs e-mature, ces cas ne donnent même pas une couverture de 80%.
Que diriez-vous d'avoir une personne QA dédiée pour écrire TOUS les tests pour un projet donné au lieu du développeur?
Y a-t-il des inconvénients à cela?

Dans le développement piloté par les tests, les tests doivent être écrits par le développeur. Sinon, une personne autre que le développeur pilote le développement.

Donc, dès que vous donnez la tâche d'écrire des tests à un non-développeur, cette personne devient développeur.

Mon expérience dans TDD est que l'écriture du code de test est souvent aussi difficile ou plus difficile que l'écriture du code de production. Donc, si vous avez des ressources capables d'écrire un bon code de test unitaire / test d'intégration, ils devraient écrire le code de production qui fait passer ces tests.

Le travail de QA consiste à effectuer un type de test entièrement différent (c'est-à-dire des tests d'utilisabilité / d'intégration). Ils n'ont pas vraiment besoin de connaître les technologies utilisées dans le code.

Si vous craignez une faible couverture de code, vous devez discipliner vos développeurs. Par exemple, arrêter de travailler sur de nouvelles fonctionnalités, jusqu'à ce que la couverture du code augmente. Certaines organisations vont jusqu'à avoir un hook de pré-validation sur leur référentiel qui ne permettra pas l'archivage du code découvert.

Enfin et surtout, dans le TTD «pur», il ne devrait pas y avoir de code découvert (puisque vous écrivez des tests en premier). Cependant, il existe des cas (bien que les gens en discutent) où une couverture de code inférieure est acceptable. Certains soutiennent par exemple que la rédaction de tests pour les getters / setters des POJO est une perte de temps.

ces cas ne couvrent même pas 80%

Cela pourrait être un problème de gestion.

Ou cela pourrait ne pas être pertinent.

Premièrement, la différence entre une couverture de 80% et 100% représente probablement beaucoup de coûts pour très peu d'avantages.

La «couverture» peut signifier n'importe quoi. Lignes de code, chemins logiques, etc. Je suppose que vous voulez dire des lignes de code (pas des chemins logiques).

Certains chemins logiques sont assez bien testés "par inspection". Le code est évident, n'a pas d'instructions if, a une complexité très, très faible et n'a probablement pas besoin d'un test supplémentaire.

20% de tests en plus, ce n'est pas toujours 20% de qualité en plus.

Seconde. C'est un problème de gestion. Si la direction veut une couverture de 100%, elle doit mettre en place un système de récompense qui récompense une couverture de 100% au lieu de "suffisamment bon pour libérer" une couverture de 80%.

Ajouter des gens QA pour écrire plus de tests n'aidera pas beaucoup.

L'ajout de développeurs pour écrire plus de tests est ce qui sera nécessaire pour atteindre une couverture de test de 100%.

Les tests unitaires à mon humble avis ne sont pas un processus d'AQ. Il s'agit davantage d'accélérer le développement (en réduisant la boucle de rétroaction pour les développeurs). Cela devrait être fait par la personne qui écrit le composant (aka unité) en mettant l'accent sur l'utilisation des composants (par un autre développeur).

Les tests fonctionnels sont un processus d'AQ qui peut et doit être effectué par une équipe d'AQ. Cela peut être fait par le développeur, mais un non développeur serait préférable car le développeur pourrait ne pas connaître toutes les façons dont un utilisateur pourrait utiliser l'application.

Les deux peuvent être effectués de manière TDD.

TDD ne concerne pas seulement les tests, mais aussi la conception. Écrire du code juste pour passer les tests conduit généralement à un code plus petit et plus facile à gérer. Si vous déléguez une autre personne pour écrire les tests, vous déléguerez également la responsabilité de créer un bon code.

Vous devez également noter que la couverture ne vous informera pas de la qualité du code et ne vous dira pas si les règles de domaine sont couvertes.

Si vous avez besoin d'une couverture d'au moins 80%, vous devez faire quelques choses:

• Fournissez à vos développeurs les outils dont ils ont besoin pour déterminer le niveau de couverture dont ils disposent - et assurez-vous qu'il s'agit de pommes à pommes. Il existe plusieurs façons de mesurer la couverture.
• Offrez une récompense / une incitation pour accomplir cet exploit. Les programmeurs ne feront que ce qu'ils estiment rentable. Si une couverture de 50% est suffisante pour garantir la qualité et faire tout le travail, c'est ce qu'ils feront.

Enfin, comprenez qu'il existe une différence entre les chemins d'exécution prévus et les chemins d'exécution non voulus . Lors de l'écriture de code piloté par les tests, vous avez peut-être prouvé que vous avez besoin d'une paire d'instructions if indépendantes. En conséquence, il existe des tests pour deux des quatre chemins d'exécution possibles disponibles. Ajoutez une autre instruction if indépendante et vous avez un potentiel pour huit chemins d'exécution (c'est-à-dire qu'elle augmente de façon exponentielle).

Comprenez que TDD ne prévoit pas nécessairement tous les chemins d'exécution potentiels, donc il y a un certain nombre de tests qui pourraient devoir être écrits pour être complets mais qui ne sont pas écrits parce qu'il n'était pas nécessaire de tester ce chemin. En bref, TDD ne garantit pas la couverture, mais il garantit qu'il existe au moins un test pour prouver la raison d' être du code qui existe.