Since I have some Rasperry PI’s which do not have a WAN connection because they are in an autonomous LAN or just do not have a WLAN module. From time to time I want to do some upgrades. So I need a connection between the LAN containing my PI’s and the WAN.
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...
This work is licensed under a Creative Commons Attribution 4.0 International License.
Many thanks to bbv Software Services AG for making this blog post possible.
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...
In the last post about the MPCC I explained how the asynchronous synchronization works by leveraging the power of a TaskCompletionSource. Today I’ll walk you through the completion method. The completion method has essentially two modes. A drain mode and a non-drain mode. In the drain mode, all items that are enqueued will be asynchronously pushed until all internal queues are empty. In the non-drain mode, the queues will be emptied but nothing will be pushed if there is something left...
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...