The first session that I am going to present at Tech.Ed this year is “Building Testable Workflows with Windows Workflow Foundation”. That is a bit of a mouth full, but the abstract provides a little bit more detail.
Abstract: Windows Workflow Foundation allows developers to visually design coordination logic between autonomous systems and host that coordination logic within their own applications. This session shows you how to build workflows with dependencies on external systems by using data exchange services to isolate them and then mock out those services to support testing of specific scenarios. Allows you to build a higher quality and more robust workflow.
When I was asked whether I could do a workflow session this year I thought about the kinds of things that I think leads to the most problems when developing and maintaining workflows that are hosted in the Workflow Foundation runtime – I came up with Building Testable Workflows because it allows me to discuss a few key issues which I think workflow developers need to be across:
- Workflows are for coordination logic.
- External dependencies should be kept external.
- Workflows need to be tested for failure.
Workflows are for coordination logic.
Long or short running, workflows are for coordination logic. One of the mistakes that I see developers making with Windows Workflow Foundation is implementing a bunch of low-level algorithmic tasks inside the visual designer, or perhaps worse discovering that is too hard and then jumping out into building custom activities that aren’t terribly reusable and have dependencies on the sibling workflow activities. In my session I look at what makes for a good workflow and how to deal with some of the heavy lifting that sometimes needs to be done in a project.
External dependencies should be kept external.
So picture this scenario. You are a software developer sitting down to make an enhancement to an existing workflow. You pull down the latest version of the source code from version control open it up – everything compiles OK but when you go to run and debug the workflow it falls over on a CodeActivity which has some hard coded external dependencies. Its not that the URL to the external web-service is hard coded, its just that the web-service doesn’t exist in your development environment anymore. The thing that really stings is that that service doesn’t have anything to do with the code change you are making but you can’t easily skip over it without drastically changing the workflow.
I guess this is a major pain point in any maintenance activity, but it is made worse in workflow because it tends to be used to integrate with external systems where the time window for accessing them for development purposes probably closed long ago.
In the session I’ll look at how to develop external data exchange services to help overcome this problem by encouraging developers to first mock out the external systems.
Workflows need to be tested for failure.
Having gone to all the effort of ensuring your workflows contain only coordination logic and all external dependencies have been mocked out, its time to make sure that you properly test the workflow. It isn’t sufficient to just test the ideal scenario, when you are doing workflow testing you need to mock your external dependencies to induce the kinds of failures that might happen in production and really understand those outcomes. There is nothing worse than putting in a loan application with a bank and having your loan approval process fall off the radar without explanation.
Workflow Foundation is an exciting building block technology for Microsoft that is already being integrated into existing product offerings. As developers we need to best understand how to work with it to produce quality code, follow these simple rules and you’ll be well on your way.