In a previous blog post we looked at testing custom WF activities using SpecFlow. In this post we will look at using SpecFlow to test the composition of custom activities. So maybe you are asking, why is this important? Surely just testing the custom activities is enough? Even though the activities are tested in isolation, and work in isolation, we need to verify that they actually work together correctly, especially when it comes to moving data between services.
More control using SpecFlow
Another reason using SpecFlow to test the composition is important, it gives our Tester more control and power over what he is able to test and subsequently make into automated tests without needing any coding background. Instead of having to run the application and test the activities with each other, and what using different activities together would produce, he can simply put a spec together. He can then run the spec and verify the result. It is now part of our automated testing pack! Furthermore, if there are bugs when certain activities are used together he can create the spec and it will guarantee we never get that bug again.
So this is what one of these specs would look like:
Scenario: Service with an assign and remote service Given I have a workflow "TestAssignWithRemote" And "TestAssignWithRemote" contains an Assign "AssignData" as | variable | value | | [[inputData]] | hello | And "TestAssignWithRemote" contains "WorkflowUsedBySpecs" from server "Remote Connection Integration" with mapping as | Input to Service | From Variable | Output from Service | To Variable | | input | [[inputData]] | output | [[output]] | | | | values(*).upper | [[values().up]] | | | | values(*).lower | [[values().low]] | When "TestAssignWithRemote" is executed Then the workflow execution has "NO" error And the 'AssignData' in WorkFlow 'TestAssignWithRemote' debug inputs as | # | Variable | New Value | | 1 | [[inputData]] = | hello | And the 'AssignData' in Workflow 'TestAssignWithRemote' debug outputs as | # | | | 1 | [[inputData]] = hello | And the 'WorkflowUsedBySpecs' in WorkFlow 'TestAssignWithRemote' debug inputs as | | | [[inputData]] = hello | And the 'Setup Assign (1)' in Workflow 'WorkflowUsedBySpecs' debug outputs as | # | | | 1 | [[in]] = hello | And the 'Convert Case (1)' in Workflow 'WorkflowUsedBySpecs' debug outputs as | # | | | 1 | [[in]] = HELLO | And the 'Final Assign (3)' in Workflow 'WorkflowUsedBySpecs' debug outputs as | # | | | 1 | [[output]] = HELLO | | 2 | [[values(1).upper]] = HELLO | | 3 | [[values(1).lower]] = hello | And the 'WorkflowUsedBySpecs' in Workflow 'TestAssignWithRemote' debug outputs as | | | [[output]] = HELLO | | [[values(1).up]] = HELLO | | [[values(1).low]] = hello |
The spec above demonstrates the following things:
- using an assign to set up some data,
- mapping this data into a remote service, and
- finally executing the remote service
How would a Warewolf developer benefit from this?
- Confirm that mapping data into and out of a remote service is working correctly.
- Debug is correctly shown and is easily identifiable between the activities that are happening on the local service and the on the remote server.
- Executing a remote service is actually working
The advantage of using SpecFlow
The most incredible advantage to having these specs is that it gives developers the freedom to swap out and change parts of the internals of the system. For example, how debug is dispatched or created or how data flows through the Warewolf during execution. The developer can execute these specs and know what is not working correctly. That kind of freedom, to me anyway, is priceless.
Again I direct you to the Warewolf open source project to get intimate details of how these specs are working and executing and encourage you to write a few of your own.
I have not touched much on the Studio side of Warewolf and that is just not fairJ. So as a final part in this series I will be doing a post about how we are using SpecFlow to define and test the UI components of the Studio.
Leave A Comment?