Comment tester unitairement un service WCF ?
-
09-06-2019 - |
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.
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.