Integration Tests in Service Fabric – The structure

In my last post, I gave a quick overview how running tests inside Service Fabric looks like both from Visual Studio and Jetbrains Rider. To be able to dive deeper into the infrastructure, I want to present the high-level component pieces first.

Every project has its own conventions how tests are componentized and structured around the production code. Many teams I’ve seen usually have a dedicated assembly per production assembly which contains a certain category of tests. For example, if you have an OrderShipping assembly you’d probably have an OrderShipping.Tests assembly that contains the tests for the order shipping component.  Since I don’t want to dive into this further, I’m going to assume that you structure your code in a similar fashion.

The Service Fabric testing approach I constructed uses conventions as much as it can to reduce complexity. Conventions, like many other approaches to design and structuring your code, have benefits and drawbacks. I specifically liked how following conventions greatly speed up the creation of new test projects for Service Fabric. So let’s assume again we want to create this OrderShipping stateful microservice which will internally use components that interact with the reliable state manager. Using the conventions we’d have to create the following things (assuming we already have an application to which we can add the order shipping service):

• OrderShipping stateful service
• OrderShippingTests stateful service
• OrderShippingTestsApplication
• AllTests class library

The OrderShipping stateful service contains the production code. OrderShippingTests will contain all the test fixtures exercising the production code in OrderShipping. OrderShippingTestsApplication is the application definition that we use to deploy the OrderShippingTests stateful service alongside with the OrderShipping code. AllTests is the client side class library which will be used to call into the test service infrastructure to report back the state of running tests to either Visual Studio, Jetbrains Rider or in the CI environment the TeamCity test runner (if you are using TeamCity).

When at a later stage we’d be creating a CustomerCare stateful service we’d we adding the following structure in a similar way we did with the OrderShipping service:

• CustomerCare stateful service
• CustomerCareTests stateful service
• CustomerCareTestsApplication
• Add additional information to the AllTests class library (covered in future blog posts)

You might wonder why I’m using this AllTests class library to become the collection container for all client side test definitions. It is not really required since it also has drawbacks that I’m going to cover in future posts. I just felt the urge to reduce the number of assemblies and it also simplifies the test execution on the CI server since the AllTest.dll will be the main entry point for all Service Fabric tests.

In the next installment, I will cover the definition of the OrderShippingTests stateful service as well as the client definition that is required inside the AllTests assembly.