18

We have a whole bunch of DLLs that give us access to our database and other applications and services.

We've wrapped these DLLs with a thin WCF service layer which our clients then consume.

I'm a little unsure on how to write unit tests that only test the WCF service layer. Should I just write unit tests for the DLLs, and integration tests for the WCF services? I'd appreciate any wisdom... I know that if my unit tests actually go to the database they won't actually be true unit tests. I also understand that I don't really need to test the WCF service host in a unit test.

So, I'm confused about exactly what to test and how.

Yeldar Kurmangaliyev
  • 33,467
  • 12
  • 59
  • 101
Esteban Araya
  • 29,284
  • 24
  • 107
  • 141
  • 1
    There is no need to UNIT tests your WCF services, it's perfectly OK to write INTEGRATION tests. – Michael Freidgeim Jul 23 '13 at 12:32
  • Avoid using mocks, a unit is not a class without any outside dependency. A unit is an end-to-end slice of business logic, even if it involves database. You can always use an in-memory or even better use an embedded database such as BerkeleyDB to test. You don't need an actual database residing on other machine. That way you can test your unit effectively without huge amount of mocking. – Narendra Pathai Nov 16 '14 at 08:31

3 Answers3

7

If you want to unit test your WCF service classes make sure you design them with loose coupling in mind so you can mock out each dependancy as you only want to test the logic inside the service class itself.

For example, in the below service I break out my data access repository using "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

On the client you can mock the WCF service itself using the interface of the service contract.

<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
Toran Billups
  • 27,111
  • 40
  • 155
  • 268
  • From http://martinfowler.com/bliki/InterfaceImplementationPair.html Using interfaces when you aren't going to have multiple implementations is extra effort to keep everything in sync.Furthermore it hides the cases where you actually do provide multiple implementations. See more examples in http://stackoverflow.com/questions/90851/is-creating-interfacesfor-almost-every-class-justified-or-are-interfaces-overus – Michael Freidgeim Jul 23 '13 at 11:37
7

It depends on what the thin WCF service does. If it's really thin and there's no interesting code there, don't bother unit testing it. Don't be afraid to not unit test something if there's no real code there. If the test cannot be at least one level simpler then the code under the test, don't bother. If the code is dumb, the test will also be dumb. You don't want to have more dumb code to maintain.

If you can have tests that go all the way to the db then great! It's even better. It's not a "true unit test?" Not a problem at all.

Jan Soltis
  • 4,320
  • 2
  • 25
  • 23
4

The consumer of your service doesn't care what's underneath your service. To really test your service layer, I think your layer needs to go down to DLLs and the database and write at least CRUD test.

Eugene Yokota
  • 94,654
  • 45
  • 215
  • 319