My first cut at this is on my Code Gallery page. The base class is called WorkflowTestFixture. It takes a generic type parameter which is the (sequential) workflow that you want to execute. The resulting test fixture code comes out looking like this:
[TestFixture]
public class TestMyWorkflow : ScottMcMaster365.WorkflowTestFixture<MyWorkflow>
{
public class TestMyWorkflow : ScottMcMaster365.WorkflowTestFixture<MyWorkflow>
{
[Test]
public void TestNormalExecution()
{ AddArgument("AccountNumber", 60005);
public void TestNormalExecution()
{ AddArgument("AccountNumber", 60005);
Run();
Assert.AreEqual(20000.00M, GetOutput("AvailableCredit"));
}
}
AddArgument, Run, and GetOutput are base class methods which set up the workflow's inputs, synchronously execute the workflow, and retrieve output parameters, respectively. The actual implementation of WorkflowTestFixtue<> is nothing special -- in fact, it comes out looking a lot like some of the code that K. Scott Allen posted for testing custom activities. (I'm not sure why Scott didn't create a base class for the stuff that he finds overly verbose. Maybe he did that in a later post that doesn't Google as well.)
Clearly there are some workflows and styles of workflow for which this approach will not work well. Right now I see it as primarily useful for sequential workflows which can execute directly to completion without a lot of external integrations with databases, services, etc. That said, I believe that still constitutes an important class of workflow. As for the limitations, I hope to remove some them in the future. Suggestions are welcome.
No comments:
Post a Comment