Je suis à peu près à créer un service Web qui sera consommé par un système personnalisé interne non .NET. Je souhaite des conseils sur la meilleure façon de configurer des cours de test et des méthodes sur une .asmx (meilleures pratiques, comment tester les appels, ce que ne pas faire, etc.) spécifiquement dans un environnement .NET 3.5.
Je vais utiliser Nunit pour effectuer ce test. Est-ce aussi simple que la création d'un projet de test, en ajoutant le service, puis créez une classe de test et une instance de ce service..then commencez à créer vos méthodes de test?
J'ai besoin de tester les méthodes .asmx et .asmx.cs (test de l'unité tester les méthodes) afin que je sache si je transmettez cela à un coéquipier que cela fonctionnera.
Peut-être qu'il n'est pas possible de tester un .asmx.cs directement et je vais devoir tester des tests d'intégration. Je suppose que ce que j'aurais vraiment besoin, c'est de se moquer de mon .asmx. Probablement pas possible.
4 Réponses :
La meilleure pratique d'un test d'unité ne doit pas tester le fichier ASMX, mais les parties (unités) derrière le fichier ASMX. Si vous pouvez diviser votre code en petits et séparés, vous pouvez également tester ces pièces.
Si vous souhaitez tester le fichier ASMX lui-même, vous parlez d'un test d'intégration. Vous pouvez utiliser Nunit pour cela dans la manière dont vous avez décrit, mais ce n'est pas vraiment des tests unitaires.
Je veux que l'unit tester les méthodes dans le. asmx.ca Donc, ma question n'a pas encore été résolue parce que dans mon projet de test unitaire, je suppose que je ne suis pas sûr de passer aux appels vers les .asmx.cs. En d'autres termes, si mon service s'appelle myservice.asmx, je souhaite créer un test d'unité MyServiceTest qui teste les méthodes .asmx.cs spécifiquement. J'ai besoin de tester les deux comme si je suis un consommateur de la servcie et du test unitaire en même temps de savoir si je reçois des erreurs à l'intérieur des méthodes .asmx.cs. Fondamentalement, le point est que j'ai créé un service interne et mon patron va l'utiliser. Je viens de faire avec les méthodes.
Je suppose donc que mes questions sont toujours debout. J'ai créé la solution MyTestSproject et dans un projet C # qui tiendra mes cours de test. Ensuite, a ajouté le projet Web à la même solution et souhaitez tester des appels sur l'unité .asmx et également un appareil test des méthodes dans l'.asmx.cs
Pouvez-vous déplacer les méthodes d'ASMX.cs (au moins les pièces à tester) dans une nouvelle classe et testez cela?
Si vous voulez vraiment tester l'ASMX (
Comme Lodewijk indiquée, il est préférable de ne pas tester l'unité du fichier ASMX. Au lieu de cela, extrayez la logique de ce fichier dans des fichiers de classe qui gèrent le comportement que vous êtes après. De cette façon, vous pouvez alors tester les classes de l'utilisateur de l'interface utilisateur. Vous constaterez peut-être que le vrai problème que vous avez est qu'il y a trop de logique commerciale dans votre couche d'interface utilisateur.
Si vous souhaitez tester le fichier ASMX lui-même, vous souhaitez rechercher des tests manuels, des tests d'intégration ou des tests d'acceptation ... mais si vous pouvez déplacer votre logique sur la couche d'entreprise, vous trouverez probablement beaucoup plus facilement tester.
J'ai déjà un projet BL pour cela. Quoi qu'il en soit, merci. Ce sont des wrappers autour des appels BL.
Malheureusement, il s'agit d'un problème de services Web .asmx, ils dépendent de ASP.NET, votre meilleure approche serait de conserver le service Web .asmx comme un talon et d'extraire votre logique de service Web dans une dépendance propre. test gratuit et test unitaire qui à la place. L'autre alternative consiste également à exécuter des tests d'intégration.
à long terme, si le test de l'unité est important pour vous, vous risquez peut-être mieux de développer l'utilisation d'un Framework web Service < / a> qui a été conçu avec des tests unitaires dès le début.
Il vous manque peut-être que le point de ce que les autres disent. Le fichier .asmx devrait avoir aucune logique qui mérite d'être testée . S'il n'est vraiment qu'un wrapper autour des appels de couche d'entreprise, il ne ajoute rien et n'a pas besoin d'être testé. Si cela ajoute quelque chose, extrayez-le jusqu'à ce que le .asasmx ne contienne que un appel transféré.
Que contient votre fichier .asmx qui ne peut pas être extrait dans des classes distinctes et testables?
Ce sont des wrappers avec une logique supplémentaire telle que la journalisation, etc. C'est un passage à mon projet Wrapper PayPal et appelle des wrappers là-bas ... mais les emballages ne sont pas toujours simplement passant sans faire de la journalisation, la mise à jour de certains enregistrements de notre côté, etc.
Je pourrais deviner extraire des classes séparées. Je vais simplement copier sur les méthodes dans une classe de test et ajouter cette classe à mon projet de test.