Test unitaire WCF

Question

Comment tester unitairement les services WCF ? Des outils tiers disponibles ?

Answer 1

Comme le dit aku, si vous testez des méthodes de service (c'est-à-dire le comportement du code), vous pouvez tester directement l'unité et contourner l'infrastructure WCF. Bien sûr, si votre code dépend des classes de contexte WCF (comme OperationContext), je suggère d'introduire des wrappers comme ASP.NET MVC le fait pour HttpContext.

Pour tester la connectivité, cela dépendra du type de points d'extrémité que vous avez configuré. Dans certains cas, vous pouvez simplement héberger votre service WCF dans le test unitaire (comme vous le feriez avec un service WCF Windows) et le tester.

Cependant, vous pouvez avoir besoin de faire tourner le serveur Web de développement ASP.NET ou même IIS si vous voulez tester le comportement WCF spécifique à ces environnements d'hébergement (c'est-à-dire SSL, méthodes d'authentification). Cela devient délicat et peut commencer à faire des demandes sur la configuration de la machine de développement de chacun et les serveurs de construction mais est faisable.

Answer 2

Je pense que la meilleure approche est de tester séparément tous les aspects ; tester la connectivité, la librairie du client (proxies) et les appels de méthode du service. Le mocking et l'injection de dépendances sont un bon moyen de tester la connectivité et le comportement du service indépendamment, mais je doute qu'ils puissent contourner les tests des points de terminaison dépendants de l'intergiciel.

Vous pouvez créer un service hôte dans votre test (auto-hébergé) et charger votre service. Une fois que vous avez configuré vos points de terminaison, vous pouvez vous y connecter en utilisant vos proxies clients. Cela devrait fonctionner avec de simples HTTP et WSHTTP. Dans votre test unitaire, vous devez créer une référence de service à votre service. Vous pouvez ensuite créer un hôte et connecter votre client à l'hôte de test. J'essaierais d'éviter tout test utilisant le "WCF Service Host" aka WcfSvcHost. (Je mentionne ceci seulement parce que quelques personnes se sont référées aux utils de Visual Studio ; qui fonctionneront seulement si vous exécutez des tests seulement de votre IDE).

Si vous devez vérifier des scénarios d'authentification exotiques ou des points de terminaison qui utilisent un intergiciel spécial, vous devrez créer des tests utilisant cet intergiciel. Pour de simples contrôles d'intégrité, etc., l'auto-hébergement est suffisant. Les tests dépendant d'un intergiciel peuvent causer des problèmes de déploiement des tests si vous utilisez un serveur de construction.

Par points d'extrémité dépendant d'un intergiciel, j'entends les points d'extrémité qui utilisent par exemple des MOM (MSMQ, RabbitMQ, etc.) ou des protocoles vraiment exotiques, etc. Peut-être que tester les proxies clients avec une maquette hébergée par vous-même et tester les points d'extrémité exotiques séparément est la meilleure solution.

Si vous souhaitez utiliser l'injection de dépendances, il existe quelques frameworks assez sophistiqués qui offrent des fonctions d'"abstraction de services" permettant d'injecter des services fictifs, etc. J'ai utilisé Spring.NET avec WCF à quelques reprises. Castle Windsor dispose également de fonctionnalités WCF.

Exemple de test auto-hébergé :

    ServiceHost serviceHost = null;

    try
    {
        var baseAddress = new Uri("http://localhost:8000/TestService");
        serviceHost = new ServiceHost(typeof (ServiceClass), baseAddress);
        Binding binding = new WSHttpBinding();
        var address = new EndpointAddress("http://localhost:8000/TestService/MyService");
        var endpoint = serviceHost
            .AddServiceEndpoint(typeof (IServiceContract), binding, address.Uri);

        var smb = new ServiceMetadataBehavior {HttpGetEnabled = true};
        serviceHost.Description.Behaviors.Add(smb);

        using (var client = new ProxyClient(endpoint.Name, endpoint.Address))
        {
            endpoint.Name = client.Endpoint.Name;

            serviceHost.Open();

            // ... magic happens 
        }

        serviceHost.Close();
    }
    catch (Exception ex)
    {
        // ... tests
    }
    finally
    {
        if (serviceHost != null)
        {
            ((IDisposable) serviceHost).Dispose();
        }
    }

Je tiens à souligner que les outils de test fonctionnel ne sont pas les mêmes que les outils de test unitaire. Les tests unitaires devraient permettre de décomposer votre test en une série de tests indépendants, tandis que les tests fonctionnels consistent principalement à tester les flux de travail de bout en bout.

Answer 3

Que voulez-vous tester exactement ? La connectivité ou les méthodes de service ?

Ce qui est bien avec WCF, c'est que vous pouvez simplement définir des interfaces (euh, des contrats) et les tester comme du code normal. Alors vous pouvez supposer qu'ils fonctionneront via n'importe quel type de connexion supporté par WCF.

La connectivité peut être testée en hébergeant votre service directement dans l'UT ou sur un serveur web de développement.

En ce qui concerne les outils, il existe des tonnes de cadres de tests unitaires : NUnit, les tests intégrés dans Visual Studio, xUnit, etc, etc.

Vous pouvez télécharger " Kit de formation Visual Studio 2008 et .NET Framework 3.5 " et " Kit de formation .NET Framework 3.5 Enhancements "Si je me souviens bien, il y avait des échantillons pour les tests unitaires WCF.

Answer 4

Si l'on veut vraiment tester les services WCF, il est préférable d'opter pour des tests d'intégration qui exercent réellement la partie connectivité client-serveur.

Answer 5

Si vous voulez tester le service en cours d'exécution, alors SoapUI est gratuit et présente d'excellentes fonctionnalités. Le seul bémol est que je ne l'ai essayé qu'avec la liaison HTTP de base.