Utilisation de Specflow avec un service Web

Question

Notre architecture d'application C# implique un service Web, une base de données et une application Winforms. L'application winforms appelle une méthode dans le service Web appelé ProcessFile. Je souhaite utiliser les techniques de développement piloté par les tests d'acceptation et écrire l'article utilisateur Specflow suivant.

Story: Process file 
As a knowledge worker 
I want to process a file 
so that it can go onto the next step. 


Given query A is True 
    And File A exists 
When I run Process with File A 
Then A backup of the existing file exists 
    And a new processed file exists 
    And query B is true 
    And query C is true 

Notre application Windows appellera l'ensemble de l'histoire du fichier de processus du service Web.

Toutefois, afin de faire BDD, nous avons été tentés d'avoir beaucoup de petits appels comme IsQueryBTrue

Il en résulte un service Web indésirable bavard et nous ne voulons pas IsQueryBTrue dans l'API publiée

I Je pense maintenant qu'un moindre mal serait pour le projet de test d'appeler le service de données directement et juste avoir quelques petits appels FileExists au service Web. Cependant, cela ne semble pas tout à fait correct, car le même code devrait sûrement être utilisé dans le test comme dans la production.

Comment puis-je tester adéquatement tout en évitant de faire un service web bavard?

Je demande maintenant si nous avons utilisé un api web ou WCF plutôt que d'un service Web wsdl

Answer 1

est de toute façon de l'API que vous souhaitez publier pour vérifier le comportement que vous attendez de votre appel à ProcessFile?

S'il y en a alors, vous devriez le faire à partir de votre scénario specflow afin de valider que le comportement est conforme à vos attentes. Cela peut être en exécutant une requête ou peut-être en visitant un autre site Web ou autre.

Si ce n'est pas le cas, vous devrez valider le comportement attendu 'interne'. Vous pouvez soit le faire via des extensions à votre service Web existant pour permettre des méthodes comme IsQueryBTrue (ou peut-être un ExecuteQuery générique). Comme vous dites que vous ne voulez pas faire cela, une meilleure solution pourrait être de fournir un autre service de test pour les tests de flux de spécification à utiliser pour valider le comportement interne. Ce service peut être fourni uniquement pour vos tests de dev et n'est pas mis à la disposition du système de production ou peut utiliser une URL interne ou des informations d'identification différentes pour s'authentifier afin de protéger l'utilisation par les personnes utilisant l'API de production.

A la fin de la journée si vous utilisez Comportement Driven Development il doit y avoir un moyen d'affirmer que le comportement du système est comme prévu et s'il n'y a aucun moyen de le faire publiquement et la seule façon est des contrôles internes que les tests doivent avoir l'accès aux systèmes internes pour vérifier. Pour moi, il semble parfaitement normal que le test appelle directement le service de données pour vérifier si les éléments nécessaires existent, en particulier si ces appels existent déjà dans ce service. Cela semble également préférable à l'ajout de nouvelles méthodes pour tester uniquement sur le webservice.