Your source of geek knowledge

Machine.Specifications – The alternative xunit

In my last post, I showed how a Heisenbug can look like to you. In this post, I want to explore the different options I was considering to get rid of some of the pesky things around Machine.Specifications. During the work, I did for Machine.Specifications I asked myself more and more if it is really worth maintaining a whole ecosystem of tools when there are excellent frameworks available in the Open Source world. Why did I even look at alternatives? Why didn’t I just say, that’s it and move away from Machine.Specifications? Continue reading

OMG! They Killed My Stacktrace!

I can’t get that flashing red light on my desktop out of my mind. It’s nagging me. What is it? Oh my… I just killed the build! How embarrassing — only a few weeks on the team and I’m already a trouble-maker. Resistance is futile. The flashing red light got me. Five acceptance tests are failing on the build server. Hold on — those tests are working on my machine! Can’t I just add a works on my machine badge and carry on with the other things I have in the work pipeline? The “getting things done guy” inside me says yes, but my engineer heart tells me no. I roll up my sleeves and start analyzing what went wrong.

If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.

Machine.Specifications – The Heisenbug

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 source library for specifications. We used SpecFlow in projects where the product owner or business analysts took the time to learn and write Gherkin. We used MSpec when the development team was writing the specifications (of course as closely as possible with the business). Continue reading

The day we almost lost an invoice

The day started like any other day working as a solutions architect for a healthcare invoice processing system. When I came into the office I didn’t anticipate that this was going to be a special day. I only realized it when a customer called in and asked for a specific invoice that should have been processed in our system. We couldn’t find it! It just wasn’t there at all. Sweat was dripping down my neck. Did we just lose an invoice — and therefore money?!

If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.

 

Participating in TransactionScopes and Async/Await Let’s get the money back!

In my last post we lost billions of dollars from a VIP customer. Let’s not do that again, shall we? In the meantime you should have bought a bigger wallet, I hope you did your homework as well. So the question is how can we improve the situation? Let do a quick recap what went wrong last time:

We were using async void to fire & forget the send operation inside the enlistment implementation. This allowed us to asynchronously dispatch the send operation without blocking the client code. The major drawback of this approach was that because of the nature of fire & forget we would not get any exceptions captured and “marshalled” back to the client. So in the case something goes wrong inside the send operation the whole operation would be lost without us getting notified.

We can address the same way unit testing frameworks are supporting async void methods. Continue reading

Participating in TransactionScopes and Async/Await Alone in the dark

In my last post I showed you how to enable asynchronous transaction flow in .NET 4.5.1 and how you can write an enlistment which participates in the transaction scope. But something went terribly wrong. I’m sure you already spotted it. Let us have a quick look at the test execution from my previous post.

FailingTest

The test execution time clearly shows that the red test took less than a second to process and then failed. How can that be when our simulated send operation asynchronously delays its execution for 1000 milliseconds and we are effectively doing three of those sends? Continue reading