MSDN Magazine - November 2008 - (Page 107)

MATT Milner Foundations Unit Testing Workflows And Activities As an author and instructor, I often get asked questions about how to test Windows Workflow Foundation (Windows WF) components. Part of learning to use a new framework is figuring out how to incorporate the tools and components into your development process. This month I will be discussing some of the challenges and techniques related to testing activities, workflows, and associated components. This is in no way intended to be a best practice guide for unit testing or test-driven development. Rather, it is meant to provide you with the techniques you can use to test your workflows in your preferred development methodology. Figure 1 Executing an Activity as Workflow Dictionary results = null; Exception ex = null; runtime.WorkflowCompleted += delegate( object sender, WorkflowCompletedEventArgs wce) { results = wce.OutputParameters; }; Dictionary wfParams = new Dictionary (); wfParams.Add("To", "mmnet30@microsoft.com"); wfParams.Add("From", "donotreply@example.org"); wfParams.Add("Subject", "Unit testing"); WorkflowInstance instance = runtime.CreateWorkflow( typeof(WFComponents.SendMailActivity), wfParams); instance.Start(); ManualWorkflowSchedulerService man = runtime.GetService (); man.RunWorkflow(instance.InstanceId); //the workflow is done, now we can test the outputs Assert.IsNotNull(results, "No results found"); Assert.AreEqual (wfParams["To"].ToString(), results["To"].ToString(), "To address was changed"); Testing Considerations When writing unit tests, you need to test common paths through your code, but things are never quite that simple. In addition to the “happy path” or the expected execution path, you also must test exception paths. In addition, many items to be tested have dependencies, and it would be unrealistic to test through them all. For example, a business object may rely on a data access layer. In testing, however, rather than relying on the database, it is common to use mock objects—objects that have the same interface as the data access layer but do not access the database at run time. These same issues are present with workflow, but in some cases the approach is slightly different. In other cases, just the fact that Windows WF is a new technology can cause some developers difficulty in deciding how to test their code. In addition to typical testing issues, using a framework like Windows WF introduces other complexities. Because Windows WF is based on a runtime that manages the execution of workflows and activities, testing must, in almost all cases, involve the use of the runtime. Many of the classes involved in the runtime execution are sealed or otherwise protected, so mocking those objects becomes nearly impossible. In addition, it would be difficult to ensure that any mock objects you created provided all of the necessary functionality found in the runtime. For those reasons, testing workflows or activities generally requires the runtime. Using the workflow runtime introduces several interesting challenges. First, because the runtime can use different schedulers, each with its own threading model, unit tests must be written with a particular threading model. The best scheduler for testing may not be the same as the scheduler that best fits the ultimate host for your workflows. The runtime provides services for developers that are helpful at run time but can make testing more challenging—exception handling, for example. The runtime catches all exceptions and manages them in the workflow. This means testing for expected exceptions will work a bit differently than in standard Microsoft .NET Framework code. When testing a solution built on Windows WF, there are several components that generally need testing: activities, workflows, rules and custom runtime services. Throughout the rest of this article, I will cover the common issues developers run into when testing these components and propose techniques for addressing them. Testing Activities When testing activities, it is important to be able to do so in isolation, providing inputs and testing outputs. Rather than testing activities in the context of a workflow, activities should be tested as individual components. Fortunately, in Windows WF, all workflows are simply activities. And that means the runtime can execute any activity as a workflow, even something as simple as an e-mail activity. Send your questions and comments to mmnet30@microsoft.com. Code download available at msdn.microsoft.com/magazine/cc135911. November 2008 107 http://msdn.microsoft.com/magazine/cc135911

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.