Question

I have been developing a WCF project that will expose web services (HTTP-based) that will be consumed by clients external to the company. I’m planning to use TFS 2010 for Continuous Integration.

I want to do continuous integration and integration testing.

my question is :

-does doing Integration tests mean that I have to create a test environment that mimics the production environment ?
-OR does it mean that I simply have to start call my WCF, Database and other objects from my unit testing tool without relying on mocks ? for example :

[TestClass]
public class ServiceIntegrationTest
{
    private static ServiceHost serviceHost;

    [ClassInitialize]
    public static void MyClassInitialize(TestContext testContext)
    {
        serviceHost = new ServiceHost(typeof(Service1), new [] { new Uri("http://127.0.0.1:8001/") });
        serviceHost.AddServiceEndpoint(typeof(IService1), new BasicHttpBinding(), "Service1");
        serviceHost.Open();
    } 

-I really don’t understand how to carry this out.
-Is there any tutorial with real world .NET (WCF) projects on how to carry this out ?

Answer 1

I’m not an expert on how to break down unit testing properly with mocks and the rest, but I can share my experience on doing integration testing with WCF / a database backend.

Basically, we used a singleton to handle all of the startup code. In otherwords, the MyClassInitialize method would call a static method that would ensure that the service hosts / database was up and running. That way, we didn’t have to set up / tear down the backend for each set of unit tests.

[ClassInitialize]
public static void MyClassInitialize(TestContext testContext)
{
    GlobalBackend.EnsureStarted();
} 

I don’t know of any examples online, you’ll likely have to do some more googling for that.

As for what granularity to write your tests at, you talked about integration tests. That sounds like you probably want to test your service calls attached to a real database. Say you have some CRUD functionality baked into your services, one unit test (integration test in this context) might create a widget (or whatever), then do a loadWidget call to make sure the widget got created correctly.

How much testing to do within one unit test (depending on whether you’re doing integration testing or more granular unit testing) is a subject that could fill many books.

EDIT: You might also need to do some cleanup / shutdown of the database / services:

MSDN Page on AssemblyCleanup attribute.

[AssemblyCleanup()]
public static void AssemblyCleanup()
{
   GlobalBackend.ShutDown();
}

Of course, that can lead to just putting all of your startup code in:

[AssemblyInitialize()]
public static void AssemblyInit(TestContext context)
{
      GlobalBackend.EnsureStarted();
}

So now I’m remembering more clearly – we ended up doing this in the end (less code)