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 my last post, I talked about me moving away from maintaining Machine.Specifications. Today I want to give you more insights into the decision process and what else I tried to save the project. When I was working for bbv Software Services AG, I was heavily using MSpec in multiple projects. I and also others in the company liked the lightweight syntax and the code-centric approach to specifications by example. We used it so much that it became together with SpecFlow one of our strategic open...
I recently announced Machine.Specifications.Resharper 1.1.0 release. This is the last release I did for Machine.Specifications. I’m taking a step back from the project. Let me give you a bit of background how I ended up maintaining Machine.Specifications and why it’s time to move on.
Today I read this blog post about how to simplify test data preparation. The author of the blog post states that setting up test data for tests is sometimes difficult and bloats up the test code, resulting in bad readability and maintainability. I completely agree with that. The author continues by solving this problem by loading the test data from a file and using it in the test. That minimizes the code needed to set-up the test data, but results in a disconnect between the test and the data...
Today we released the next version of Machine.Specifications. This release implements an important feature to move on in the future. We implemented a complete runner dependency abstraction. What does that mean? Let me take a step back. The picture above shows the state of Machine.Specifications previous to V0.9.0. The console runner, the resharper runner, the TDnet runner and more were directly dependent upon the same Machine.Specifications version. This means when we release a new...
This work by Urs Enzler is licensed under a Creative Commons Attribution 4.0 International License.