Why would you want to test your Windows Workflows and WF Services?
As a an avid NServiceBus admirer my curiosity about the testability of Workflows in .NET 4.0 led me to ask the question in a group setting recently. One of the responses was “why would you want to test a workflow”? The respondent continued with “surely you would only unit test the components leveraged inside a workflow”? I have to disagree with this assertion! I do want to test my workflows because of reasons such as:
- I’d like to know if a given message types and content cause my workflow to behave exactly as I expect.
- Did my order submission publish a message to any other endpoints interested in the state of the order submissions outcome?
-
If the current state of my workflow is about to be de-hydrated, what are my expectations after handling a given message, were the subsequent expected events raised and or messages sent?
These kinds of concerns when dealing with long running processes in my services really do matter – the business requires such co-ordination to work or fail as described by specification and business workflows inherently contain testable logic - think of your average state machine or consider SLA’s where a de-hydrated (persisted) workflow has passed an acceptable time boundary, raising events commensurate with that business condition. Sure I need to test my business components too but the story is bigger than that!
NServiceBus Sagas are probably the closest correlation to a workflow in the WF stack and Sagas are eminently testable with a baked in testing API designed for the purpose. I guess it’s time to check what WF 4.0 has to offer and see what the story is for myself. More on that a bit later.
