Question

Nous disposons de tout un tas de DLL qui nous donnent accès à notre base de données et à d’autres applications et services.

Nous avons enveloppé ces DLL avec une fine couche de service WCF que nos clients consomment ensuite.

Je ne sais pas trop comment écrire des tests unitaires qui testent uniquement la couche de service WCF.Dois-je simplement écrire des tests unitaires pour les DLL et des tests d'intégration pour les services WCF ?J'apprécierais toute sagesse...Je sais que si mes tests unitaires vont réellement dans la base de données, ils ne seront pas réellement de vrais tests unitaires.Je comprends également que je n'ai pas vraiment besoin de tester l'hôte du service WCF lors d'un test unitaire.

Donc, je ne sais pas exactement quoi tester et comment.

Était-ce utile?

La solution

Le consommateur de votre service ne se soucie pas de ce qu'il y a sous votre service.Pour vraiment tester votre couche de service, je pense que votre couche doit descendre jusqu'aux DLL et à la base de données et écrire au moins CRUD test.

Autres conseils

Si vous souhaitez tester unitairement vos classes de service WCF, assurez-vous de les concevoir en gardant à l'esprit un couplage lâche afin de pouvoir simuler chaque dépendance, car vous souhaitez uniquement tester la logique à l'intérieur de la classe de service elle-même.

Par exemple, dans le service ci-dessous, je décompose mon référentiel d'accès aux données en utilisant "Poor Man's Dependency Injection".

Public Class ProductService
    Implements IProductService

    Private mRepository As IProductRepository

    Public Sub New()
        mRepository = New ProductRepository()
    End Sub

    Public Sub New(ByVal repository As IProductRepository)
        mRepository = repository
    End Sub

    Public Function GetProducts() As System.Collections.Generic.List(Of Product) Implements IProductService.GetProducts
        Return mRepository.GetProducts()
    End Function
End Class

Sur le client, vous pouvez vous moquer du service WCF lui-même à l'aide de l'interface du contrat de service.

<TestMethod()> _
Public Sub ShouldPopulateProductsListOnViewLoadWhenPostBackIsFalse()
    mMockery = New MockRepository()
    mView = DirectCast(mMockery.Stub(Of IProductView)(), IProductView)
    mProductService = DirectCast(mMockery.DynamicMock(Of IProductService)(), IProductService)
    mPresenter = New ProductPresenter(mView, mProductService)
    Dim ProductList As New List(Of Product)()
    ProductList.Add(New Product)
    Using mMockery.Record()
        SetupResult.For(mView.PageIsPostBack).Return(False).Repeat.Once()
        Expect.Call(mProductService.GetProducts()).Return(ProductList).Repeat.Once()
    End Using
    Using mMockery.Playback()
        mPresenter.OnViewLoad()
    End Using
    'Verify that we hit the service dependency during the method when postback is false
    Assert.AreEqual(1, mView.Products.Count)
    mMockery.VerifyAll()
End Sub

Cela dépend de ce que fait le service Thin WCF.S'il est vraiment mince et qu'il n'y a pas de code intéressant, ne vous embêtez pas à le tester unitairement.N'ayez pas peur de ne pas tester quelque chose s'il n'y a pas de vrai code.Si le test ne peut pas être au moins un niveau plus simple que le code sous le test, ne vous embêtez pas.Si le code est stupide, le test le sera également.Vous ne voulez pas avoir plus de code stupide à gérer.

Si vous pouvez avoir des tests qui vont jusqu'à la base de données, alors tant mieux !C'est encore mieux.Ce n'est pas un "véritable test unitaire?" Pas un problème du tout.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top