Mon patron veut que je crée une page .aspx, de textes de texte pour la simplicité pour la saisie d'informations de carte de crédit afin que nous puissions tester certaines méthodes de notre service de carte de crédit.
C'est bien, mais je penserais que nous pourrions faire un test unitaire pour cela. La seule chose est que, au lieu de taper les trucs dans un formulaire Web, nous changerions simplement les valeurs variables passées dans le test de l'unité.
Quelqu'un peut-il me dire si nous sommes fous de ne pas effectuer un test de l'unité au lieu d'une page .aspx pour tester et entrer dans des données de test pour tester quelques appels à certaines de nos méthodes?
Il finira par me dire que le test de l'unité prend trop de temps pour la configuration (comme j'ai essayé de lui dire que nous devons faire des tests unitaires) qui est une excuse stupide boiteuse.
8 Réponses :
Au lieu de cela, vous pouvez écrire un test simple (ou Java) qui appelle le service Web et vérifie différents scénarios, ainsi que l'avantage évident (c'est TESTABLE), vous aurez également un moyen automatisé de vérifier ses fonctionnalités.
Le temps "gaspillé" sur la rédaction des tests unitaires sera repris par le temps enregistré sur tester le même scénario encore et encore au lieu de simplement exécuter les tests automatisés.
Si votre patron n'est pas convaincu par celui-ci d'étudier qui montrent TDD / Efficacité des tests de l'unité .
Si tout le reste échoue, pourquoi ne pas utiliser un outil automatique comme soPui au moins vous vous sauverrez de tester manuellement la même fonctionnalité encore et encore.
Oui, je lui ai dit que nous ne pouvons que réexécuter ces tests plus tard.
Mon patron est un bon codeur, ce n'est que le cas d'un environnement et d'un environnement de code qui est conduit.
Ensuite, vous devriez proposer à l'aide d'un cadre "Automation" SOAP - voir ci-dessus
Vous êtes fou si vous ne testez pas votre service Web au lieu d'écrire un harnais de test manuel :)
Fondamentalement, un service Web est une API accessible sur un protocole distant, alors pourquoi ne pas le tester unitaire?
D'accord. Testez le code en dehors de la publication WebService ... Cette couche est principalement de la configuration. La chose qui compte est le code. Écrire des tests d'unité pour tout ce qui y est. Tu seras content de l'avoir fait.
À mon avis, si vous créez une page .aspx et obtenez la valeur du formulaire Web, ce serait un test de temps plus réel que les tests unitaires. J'espère que le service Web était déjà testé par l'organisation, qui vous fournit ce service Web. Je pense que vous devez juste créer .aspx forme et obtenir votre travail.
Vous pouvez effectuer des tests unitaires pour toute votre satisfaction du processus de développement. Il est judicieux que la personne qui ait été effectuée par la personne qui a écrit le code de la méthode de la classe / de la fonction / Web.
Faites-moi savoir si vous avez des questions.
Nous avons créé le service Web pour la consommation en interne.
Les tests unitaires ne doivent pas être un "pour votre satisfaction". C'est pour toute l'équipe et d'améliorer les tests, le codage et bien plus encore.
>> Cela ne prendra pas trop de temps. Eh bien, cela dépend si vous êtes un débutant ou non dans des tests unitaires.
Dans la mesure où ma compréhension, le développeur doit toujours écrire un test de l'unité, quel qu'ils soient codés.
Si c'est un service Web ASMX, vous pouvez essayer d'activer le protocole httppost dans votre web.config: Ceci permettra au formulaire de test pour le service Web lorsque vous visitez le site Web. page dans votre navigateur. Cela pourrait ne pas bien fonctionner pour des types complexes; Mais si vous avez des types complexes, il sera plus facile de construire les tests d'unité qu'un formulaire personnalisé de toute façon. L'argument selon lequel le test de l'unité est plus difficile qu'un formulaire Web semble tromper; Si vous développez une forme, vous devez écrire le code client de service Web de toute façon, en plus de construire la page elle-même.
Exactement, vous faites double travail. Vous devez créer un formulaire en dehors de la logique de test.
Votre patron peut souhaiter confirmer que le service Web peut être En écrivant un test d'unité réel pour le service Web, je pense que vous avez déjà perdu la bataille cette fois-ci ....
La prochaine fois, essayez d'écrire des tests de l'unité pour chaque méthode des appels de services Web, juste avant ou juste après avoir écrit la méthode. Il n'est pas nécessaire de dire à votre patron que vous faites cela, car cela entraînera une production de code de travail plus rapide.
Vous pouvez toujours passer une partie de votre temps ce soir, une fois que votre patron est rentré chez lui, essayant d'écrire les tests de l'unité. Puis seulement lui dire ce que vous avez fait lorsqu'il vous demande pourquoi votre code n'a pas de bugs.
Les méthodes appelées discutent de parler à une base de données, mais je parle de tester les appels de méthode, et non de la base de données appelle ici. Et de toute façon si je voulais vraiment tester ces méthodes de service qui envoient des mises à jour / adviennent à une base de données, je pourrais vous moquer.
J'aime votre approche de le faire quand même en dehors du travail. Cela m'aidera au moins à long terme si je ne peux pas convaincre cet endroit pour le moment.
C'est une bataille que vous allez sûrement perdre. Vous devez vous mettre dans vos chaussures de bosses. Il existe des projets dans lesquels des tests unitaires pourraient prendre trop de temps, en particulier à la fin du cycle de développement lorsque tout est précipité pour être achevé. TDD doit être suivi du début ou vous perdez trop de temps à mettre en œuvre des tests d'unité Après avoir déjà oublié comment fonctionne un morceau de code spécifique (non, les commentaires ne suffisent généralement pas).
Il suffit de faire une pratique courante pour les prochains projets que vous faites TDD. Une fois que toute votre unité de code testée, vous pouvez implémenter un type de test fonctionnel avec des outils tels que JMeter et selenium .
Oui et j'essaie de commencer maintenant.
>>> C'est une bataille que vous perdez sûrement. Vous devez vous mettre dans vos chaussures de bosses. Je ne suis pas d'accord. Les bons gestionnaires savent incorporer ou au moins regarder cette option car il s'agit d'un excellent processus. Les mauvais gestionnaires sont ceux qui donnent des excuses à ne pas repousser pour des tests pour l'équipe et l'entreprise. Je m'en fiche si mon manager est sous pression ou son manque de capacité à ralentir et à faire des choses avec des normes à pied chaque jour. Je me soucie de faire des choses correctement et de gagner du temps et de la frustration à long terme. Donc non, je ne vais pas parce que cette personne ne se soucie que de courir
Et moi-même dans une chaussure de Code & Run Manager est l'une des principales raisons pour lesquelles elle et les entreprises échouent continuellement à la fois du côté de l'équipe et de la production.
Donc, je n'ai aucune sympathie pour ce manager qui ignore totalement l'idée qui profite au globe de la société à long terme en raison d'excuses boiteuses ou de raisons que "il nous ralentit" "
Ce que je voulais dire, c'est que sur certains projets où des tests unitaires sont introduits trop tard, il n'y a pas de temps pour les tests d'unités. Vous devez faire avec ce que vous avez déjà.
deviner que vous avez déjà perdu la bataille (nous ressentons pour vous). Il existe de meilleures solutions que de créer manuellement un consommateur pour votre service Web.
Consultez soPui . Il consomme votre WSDL et vous permet de jouer avec les demandes XML. Très facile à brancher dans un service Web pour le tester si tout ce qu'ils veulent, c'est un POC.
Je me sens un peu coupable de quitter une telle gloi de réponse comme je l'ai déjà fait, alors voici une prise plus sérieuse sur celle-ci:
Examinons ce qu'il faudrait à l'unité Test du service. Un test d'unité réel est un test automatisé qui teste une seule unité (dans votre cas le service Web sans aucun système de backend, tels que des bases de données, etc.). Comme d'autres l'ont souligné, des tests d'unités appropriés du service sont probablement trop tard dans ce cas.
Cela ne signifie pas que vous ne pouvez pas utiliser de test unitaire framework (tel que Mstest, Xunit.net, Nunit, etc.) pour piloter vos tests de service. Contrasions que scénario pour développer une page ASPX à deux points:
alors qu'est-ce qui est différent?
En conclusion, je dirais que si vous n'insistez pas pour effectuer des tests d'unité réels dans ce cas, mais simplement utiliser un cadre de test d'unités pour écrire les tests automatisés, vous devriez être mieux éteint. avec les tests automatisés qu'avec la page ASPX. L'effort de développement sera plus ou moins identique.
Pour votre prochain projet, vous pouvez alors voir si vous pouvez utiliser TDD depuis le début, mais c'est une autre bataille.
bonne chance.
>>>> dans le scénario ASPX, vous devez écrire du code qui prend les données de réponse (non pas avec ces appels, ils renvoient un dos int ou booléen)
Je ne pense pas que plus de code est un problème, mon code et le patron d'exécution fait.
Il est impossible de changer de code et de gérer des tests automatisés. Croyez-moi.
Qu'en est-il de la configuration de cette page ASPX et de l'exécution de tests via un outil comme selenium ou JMeter (lien dans ma réponse ci-dessous)? Grant que vous devriez modifier les tests de sélénium lorsque vous changements de service Web, mais vous pouvez toujours l'exécuter sur demande avec des résultats mesurables. En cas de sélénium, vous pouvez même utiliser le plugin Firefox pour faciliter la création de "tests d'unité".
Bonne chance - j'espère que vous gagnerez cet argument
Appeler les idées de votre patron boiteux et stupide n'est pas le meilleur moyen de le convaincre que TDD a raison. :-) Peu importe si vous utilisez un test de l'unité, il serait peut-être une bonne idée de configurer une simple page .aspx pour tester manuellement des scénarios spécifiques.
Je suis sur le côté d'une bataille perdue. "Nous n'avons pas besoin de faire ça, c'est trop cher"
Je n'appelle pas mon patron boiteux et stupide à son visage évidemment. Je ne suis pas si "stupide"
Mais c'est stupide. Je dis la vérité. Désolé, je ne fais pas de sucre en manteau quand je posterai.
Le temps qu'il vous a fallu pour écrire cette question, vous auriez pu créer les tests de l'unité et dire: "Hey, Boff, regarde ce que j'ai fait!" Demandez le pardon, pas la permission. De plus, je pense que votre patron est aussi stupide. C'est un gros mannequin. Mais alors, je ne travaille pas pour lui. Pensez, ce n'est pas le chômage, son champ de convité.