Windows Workflow Foundation offers some powerful capabilities for those working with data flow style architectures. But these capabilities come at a cost. Unlike traditional batch processing applications, Windows Workflow Foundation does not lend itself to automated testing.
There are several attempts at making testing more palatable with mixed results. Ron Jacobs tests activities using a custom activity and workflow. Some like Maurice de Beijer don't agree with that approach,
Most people consider unit testing of custom workflow activities to pretty much impossible. Sure you can create a dummy test workflow containing your new activity, new up a WorkflowRuntime, create a WorkflowInstance and start it. But just think about all the dependencies here with the extra dummy workflow and the complete WorkflowRuntime with all its dependencies. Hardly a unit test for an activity but more like an integration test. Now there is nothing wrong with integration tests, they are very useful and necessary, but they do not give the speedy and dynamic test coverage you expect and need from a unit test.
Much of the problem with performing unit tests is that ActivityExecutionContext is sealed. Maurice gets around this by using TypeMock to sidestep this restriction.
Unfortunately, both of these are still far more complex than what is required when developing dozens if not hundreds of automated tests. Hopefully future developments will change this.
Community comments
This is like GUIs, no?
by Francois Ward,
Re: This is like GUIs, no?
by Gil Zilberfeld,
This is like GUIs, no?
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
I mean, Workflow foundation is similar to separating presentation from logic... You just separate logic from orchestration.
If you make your workflows the same way you make your UIs (that is, no actual work done in the workflow, it should just pass the context info to the services), then its not so bad.
Workflow Foundation as a whole is based on "dependency-injection-like" stuff: do everything using external method activities. That means that all of the "services" the Workflow uses need to implement an interface, and you HAVE to "inject" the dependencies (the implementation of the interfaces) in the runtime. You have to wether you want to or not. Even the "built in" services can be replaced by your own implementations.
Also, all of the input parameters of workflows have to be "injected" too.
So you can unit test the implementation of the interfaces like you would any other interface implementation, that one is easy. Then you can unit test the workflow itself like you would any other object in isolation. Mock the interfaces, send parameters, assert the state of the mocks afterward.
You'll only run into issues if you go too exotic with what you do in the workflow, and thats true for everything...if your objects aren't well decoupled, you're screwed... same with Workflow Foundation. It has tools that let you shoot yourself in the foot: you shouldn't use them, and unit testing is the LEAST of your worries here (-versioning- is the primary issue).
I was actually amazed at how easy it was to unit test workflows, personally. Its already well designed and loosely coupled, no need to be creative, unlike, let say, WebForms.
Custom Activities are just like any other custom component. Even the samples provided by microsoft are mostly implemented with external events and external methods activities. If you do that, you virtually don't have to unit test the activity itself (test the workflows instead). You'll have to test your workflows themselves anyhow, so you'll already have what it takes to decouple a dummy one. Piece of cake.
Re: This is like GUIs, no?
by Gil Zilberfeld,
Your message is awaiting moderation. Thank you for participating in the discussion.
Like Maurice says, it's a question of using the correct tool to isolate the dependencies. Once you do, you can unit-test anything. And Isolator is the best tool for the job, since it can help unit-test anything.
I don't see faking the sealed ActivityExecutionContext by Isolator as a side-step, rather as using the right tool to solve a real problem.
Gil Zilberfeld
Typemock