Tester votre code par programme: par le programmeur ou quelqu'un d'autre?

Question

Voici donc la situation - une citation de mon patron: [...] Nous devons nous concentrer sur la programmation. [...] À la fin de la journée, je veux écrire de bons logiciels et ne pas m'enliser avec les tests . " Cela est dit après que nous ayons eu 3 mois d'une liste intimidante de bogues et récemment désigné un non-programmeur pour rédiger des tests Web avec Selenium Framework.

Mon patron est très timide d'unité (il ne peut pas voir l'avantage de coût lorsqu'il ralentit les développeurs). Quelles sont vos opinions sur les tests Web et les tests programmatiques en général? Devraient-ils être écrits par le programmeur (ou a) ou est-ce important? Ma pensée faisait partie de l'écriture de bons logiciels, les tests d'écriture sont-ils des tests? C'est un type de type ivoire Microsoft, et donc toutes les ressources qui ont été publiées par Microsoft (ou les bons articles en général) en faveur des tests par conception seraient utiles.

Answer 1

Voici ce que j'ai fait.

1. J'ai quand même écrit les tests.

2. J'ai écrit le code après avoir écrit les tests.

3. Le code était solide et (surtout) sans bug (aux limites de mes capacités.)

Je n'ai jamais dit à personne que je faisais TDD. À moins qu'ils ne le demandent.

Il s'avère que TDD est en fait plus rapide que de jouer à essayer de concevoir quelque chose, de le coder et d'espérer que cela fonctionne.

Quelques choses incluent une étape supplémentaire 0: une "pic de technologie" pour voir comment les choses fonctionnent. Ceci est suivi par un certain développement de tests pour exercer le vrai logiciel, mais non écrit.

Je suis un peu en retard sur le point de départ de la conception. Étant donné que mon design est "des tests de conception et d'écriture pour ce design" alors que d'autres conceptions sont "grattant avec des idées intelligentes mais pas de vraie preuve". Certaines personnes peuvent bien concevoir sur papier. Je ne peux pas. Mais je peux concevoir des tests.

Je suis généralement assez loin en avance quand il s'agit de terminer le code. Depuis - quand j'ai fini de coder - tous les tests passent.

Answer 2

Code complet est un livre qui fait partie de la collection Microsoft. Il contient des conseils préconisant l'examen par les pairs et brossant les tests unitaires comme concept. Cela ne va pas trop loin dans les détails avec des tests unitaires, mais cela peut le réchauffer à l'idée et vous pouvez explorer davantage le sujet à partir de là.

En fin de compte, vous avez besoin de quelqu'un qui est un programmeur directement impliqué dans l'automatisation des tests ... Je veux dire, c'est par définition.

Les tests unitaires sont plus efficacement écrits par les personnes qui connaissent le plus les sous-systèmes pour lesquels ils sont écrits, lorsque quelqu'un d'autre est choisi pour écrire des tests unitaires, il leur faut du temps pour augmenter, et qu'ils peuvent manquer l'intention non documentée ou claire dans le code ce qui pourrait entraîner une pire couverture. D'un autre côté, le propriétaire du sous-système peut également être aveugle à certaines lacunes (mais c'est à cela que servent les avis de code par les pairs!)

---

Le reste est vraiment une discussion inactive sur l'éthique, mais il est important de considérer.

Certaines personnes aiment essayer de "se faufiler" à la construction lorsque la direction prend des décisions idiotes. Cela me rend non seulement mal à l'aise, mais aussi en quelque sorte méfiant à propos de ces programmeurs. Je comprends la motivation, je pense que nous avons tous été là, mais en fin de compte, vous devriez éduquer plutôt que participer à Subterfuge.

La direction joue un rôle important dans la planification et ils comptent sur vous pour les estimations précises et une compréhension générale du travail effectué. Si vous remplissez vos estimations pour balayer un travail supplémentaire sous le tapis, est-ce vraiment une bonne chose? Ce qui a été un simple mensonge devient ce canular élaboré que vous jouez sur les personnes directement impliquées dans l'aide à votre carrière.

Ce qui était un problème avec le processus et l'estimation du travail légitime est maintenant devenu un problème d'éthique collant.

Je vous recommande fortement de procéder à votre approche planifiée de convaincre votre manager de voir votre point de vue à travers la raison, la logique et l'appel à son amour de Microsoft. ;)

À long terme, si vous vous trouvez constamment à combattre la gestion sur les décisions concernant le processus de programmation (ce qui n'est vraiment pas leur travail pour prendre des décisions), il serait probablement préférable de polir ce curriculum vitae et de trouver un meilleur emploi.

Une partie du travail d'un programmeur consiste à éduquer les personnes impliquées qui ont moins d'expertise. Expliquer qu'à votre manager peut aider à briser certaines des barrières intellectuelles qu'il a sur le sujet et à l'adoucir pour accepter vos conseils sur la question.

Answer 3

Je vais pour le monde que pour que quelque chose soit «fait», il doit avoir été vérifié par au moins deux personnes. Vous n'avez pas toujours besoin d'un testeur de logiciel dans l'équipe si tout le monde dans l'équipe croit que la qualité du logiciel est le travail de chacun.

Si vous voulez qu'il soit très efficace, le développeur écrivant le code devrait écrire les tests et quelqu'un les examine avec le code de production. Si vous voulez être très efficace, associez-vous à quelqu'un et écrivez les tests pendant que vous écrivez le code dans un "TDD apparié".

Rappelez au gestionnaire que le coût des bogues augmente de manière expontable plus tard, il est trouvé.

Answer 4

Je comprends d'où vient votre patron. Après tout, les programmeurs devraient être en mesure de produire du code qui "fonctionne". Cependant, les tests sera se produire quoi qu'il arrive, que ce soit des tests unitaires, des tests d'intégration dans votre entreprise ou après l'installation du client. Les erreurs à chacune de ces étapes ont des coûts et des conséquences différents, cependant ...

Answer 5

Vous entendrez souvent que c'est une bonne idée de faire tester d'autres personnes votre code, car ils pourraient interpréter la spécification différemment. Cependant, l'avantage d'écrire les tests de votre propre code est que vous savez où il peut être défectueux.

Une approche efficace pourrait être un mélange des deux: le programmeur écrivant ses propres tests unitaires, en se concentrant sur les cas d'angle et quelqu'un d'autre qui fait des tests fonctionnels, en se concentrant sur la spécification de niveau supérieur.

Answer 6

Tous les tests ne sont pas créés égaux, passons en revue:

• Tests unitaires / TDD. Il est difficile de se disputer, surtout comme le contraire de "Il ne peut pas voir l'avantage de coût quand il ralentit les développeurs", c'est plus rapide. S. Lott passe en revue les détails.
• Tests d'intégration ciblés. Comme ci-dessus, c'est plus rapide. Pas d'avoir à exécuter une série d'étapes via votre application entièrement intégrée, pour savoir si cette couche très mince de code d'intégration que vous venez d'écrire fonctionne. C'est pire quand on considère que cela est répété car plusieurs fois, vous devez y aller, et encore plus quand cela devient mal couplé à différents processus.
• Tests système complets. Avec ce qui précède en place, vous voulez juste savoir si toutes les pièces étaient correctement accrochées et si l'interface utilisateur fonctionne comme prévu. Pour le plus tôt, vous avez besoin d'un tout petit peu de tests qui sont très rapidement écrits; Comparez cela à combien de fois les gens passent manuellement dessus (y compris vous-même) et vous avez un gagnant :). Pour le dernier, il y a certaines choses difficiles à attraper avec des tests automatisés, vous ne concentrez donc pas l'automatisation sur ceux-ci.
• Tests exploratoires. Ceux-ci devraient encore être faits, espérons-le, suffisamment de réflexion est soumise avant que la fonctionnalité ne soit construite pour éviter d'avoir à apporter des modifications supplémentaires à ce stade.

Maintenant, QA propose généralement des scénarios supplémentaires. C'est bien, mais c'est le mieux quand il est inclus de manière collaborative dans les tests automatisés.

Un vrai problème peut être les compétences en équipe actuelles. Les tests unitaires sont plus difficiles, plus le code est couplé, c'est généralement le pire avec le code existant sans tests unitaires, mais il est également initialement plus difficile d'aller de l'avant pour un développeur qui ne sait pas bien comment concevoir le code de manière lâche / élevée Code de cohésion. Cela doit être fait, mais soyez conscient de cela car le coût ira quelque part (aux membres de l'équipe ou à l'entreprise).

Answer 7

Pour créer une bonne suite de tests, cela demande beaucoup d'efforts; Cela prendra plus de temps que prévu.

À cet égard, votre patron a raison.

Cependant, si vous prévoyez d'étendre votre produit (ajouter des fonctionnalités) ou le site Web (ajoutez des pages et du code JavaScript), vous devez quand même créer la suite de la suite plus tard.

Answer 8

Tu pourrais souligner que tests unitaires est intégré dans le framework .NET depuis VS2005.