We use event sourcing in many sub-systems of our application to store data. We serialize the data of the events as JSON and store the JSON in the database. To ensure that we don’t change the structure of these event data and by this introduce backward compatibility issues, we use Verify to snapshot test the event data.
Unquote is a great library for writing test assertions in F#. In our acceptance tests, we frequently check data structures for equality. When these data structures get bigger, reading test failure messages gets harder. That’s why I implemented an F# data structure differ around Unquote that lets me quickly see the differences.
In the previous post, I explained the inner workings of the communication listener and how it uses NUnitLite and a custom code to cache test names. In this post I’ll show how the NUnitTestAssemblyRunner is used to run individual tests when the client calls the Run method with individual test names. Without further ado The Run method executes the actual test run on a dedicated worker thread. With the setting of SynchronousEvents set to true introduced in the previous blog post, all event...
In the previous post in my series on integration tests in Service Fabric I walked my readers through the AbstractTestRunner whose responsibility it is to discover tests in combination with the communication listener and exposes all the discovered tests to the client to be able to run individual tests over Service Fabric Remoting. In this post, I will introduce the communication listener which contains the actual test runner and discovery process which uses NUnit. Service Fabric SDK provides an...
In the last post in my series on integration tests in Service Fabric I showed how it is possible to use the C# API of the Service Fabric SDK to deploy the test applications dynamically to the cluster. The approach showed also used a ServiceProxy client that was able to interact with the server-side hosted inside the cluster over Service Fabric remoting. The service proxy is responsible for querying all tests that are hosted inside the test application and then instruct the service to run them...
In the most recent post, I showed how the R base class fetches all the test definitions from the cluster and executes the tests one by one. In this post, I will walk you through the client side deployment. One of the nice benefits of Service Fabric is that it provides out of the box a relatively complete deployment story. It is possible to deploy application packages entirely in code by using Powershell or C#. All you need for that to work is the latest SDK. To deploy an application to the...
In the last post, I showed how it is possible to write test fixture that gets access to the reliable state manager and more that is only available when running on the cluster. In this post, I’ll explain the client side that interacts over remote proxies with the tests that are running on the cluster. In the post about the test definition I showed that in order to interact with the tests defined in the OrderShippingTests stateful service that is deployed with the...
Previously I explained how the test definition works. In this post I’ll show how we declare tests and get access to the infrastructure provided by the stateful service. Components that are used inside a stateful service most likely end-up using either the StatefulServiceContext, the IStatefulServicePartition, the IReliableStateManager or other methods and properties provided by the stateful service inheritance hierarchy. Let’s have an oversimplified look at how the hierarchy looks...
In the last post I gave an overview of the conventions that drive the solution structure and define the test applications. All the code I’m going to explore in this, and future blog posts can be found on my ServiceFabric.Testing repository. The code in the repository doesn’t use the OrderShipping analogy used in the post, but I’ll hope you still get the point ;). The OrderShippingTests project stateful service has to inherit from the stateful service called AbstractTestRunner...
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...