Windows Workflow Foundationは、データフロースタイルアーキテクチャに取り組んでいる人びとにパワフルな機能を提供する。しかしこうした機能は、費用がかかる。 従来のバッチ処理アプリケーションとは違い、Windows Workflow Foundationは自動化テストには役立たない。
テストを結果とよりうまくいくようにさせるいくつかの試みがある。Ron Jacobs氏は、カスタムアクティビティおよびワークフロー(リンク)を使用して、アクティビティをテストしている。Maurice de Beijer氏をはじめとする人たちは、そのアプローチをよしとしない。
たいていの人は、カスタムワークフローアクティビティのユニットテストはかなり不可能だと見ている。確かに、新たなアクティビティを含んだダミーのテストワークフローをWorkflowRuntimeで作成することができる。WorkflowInstanceを作成し、それを開始することができる。しかし、追加のダミーワークフローとのすべての依存関係を考え、すべての依存関係でWorkflowRuntimeを 完了させる。ほとんどアクティビティ向けのユニットテストではなく、むしろ統合テストのようなものである。統合テストには何の問題もなく、非常に便利でなくてはならないものであるが、期待するようなスピーディーでダイナミックなテストを提供するわけではなく、ユニットテストのニーズに応えることはない。
ユニットテストの実施に関する多くの問題は、ActivityExecutionContextがシールされていることである。Maurice氏はTypeMockを使用し、この制限を回避すること(リンク)でこれに取り組んでいる。
残念なことに、これらのどちらも数百の自動化テストとまではいかなくとも、数十を開発する際の要求よりもまだ複雑である。願わくば、今後の開発でこの点が修正できればよいと思う。