As I mentioned in Part 2 of this series, I would write about how we are using SpecFlow for the Studio rewrite. Although this post does not have anything to do with Windows Workflow Foundation, it is the final part of the “Testing Custom WF Activity using SpecFlow for Warewolf series” and ties up our journey with SpecFlow so far.
Now as you may or may not know there are UI testing frameworks out there already. Each has a different way of testing from using screenshots to providing hooks using UIAutomation. We have found that none of these frameworks gave us enough flexibility, execution speed and lack of fragility.
Enter SpecFlow
Having had so much success using SpecFlow to define and test other parts of the Warewolf ecosystem, it was natural to want to be able to do the same thing with the Studio. After some leg work we were able to achieve this using the Microsoft Coded UI framework and some magic from us. Below is an example of how a UI spec for the current Studio would be:
Scenario: ChangeWorkflowMappingsAlertsAffectedOnSave Given I have Warewolf running And all tabs are closed And I click "EXPLORERFILTERCLEARBUTTON" And I click "EXPLORER,UI_localhost_AutoID" ##Searching Workflow with the name "InnerWF" in explorer search And I send "InnerWF" to "EXPLORERFILTER" ##Opening WF from explorer And I double click "EXPLORERFOLDERS,UI_Acceptance Testing Resources_AutoID,UI_InnerWF_AutoID" And I click "VARIABLESCALAR,UI_Variable_result_AutoID,UI_IsInputCheckbox_AutoID" When I click "RIBBONSAVE" Then "UI_DeleteResourceNoBtn_AutoID" is visible within "2" seconds When I click "UI_ResourceChangedWarningDialog_AutoID,UI_ShowAffectedWorkflowsButton_AutoID" Given I double click point "500,96" on "UI_DocManager_AutoID,UI_SplitPane_AutoID,UI_TabManager_AutoID,myScrollViewer" Given I double click point "482,121" on "UI_DocManager_AutoID,UI_SplitPane_AutoID,UI_TabManager_AutoID,myScrollViewer" Given I double click point "649,200" on "UI_DocManager_AutoID,UI_SplitPane_AutoID,UI_TabManager_AutoID,myScrollViewer"
As you can see they are not as descriptive and easy-flowing as the specs we have written in other parts of the system. However at the time they were desperately needed and much better than what we had previously.
We draw the line here, this far, no further
Over the years many have had their hand in the development of Warewolf and unfortunately at times quality within the code base had dropped. Some fundamental architectural flaws and bad decisions had been taken resulting in the maintenance that we know all too well. As a team we decided it was time to draw the line. We acknowledged that the Studio needed a re-write, a process that we are currently busy with and super excited about.
A brighter and better specified UI
Part of this Studio rewrite meant re-looking at how our UI specs were being done and trying to find a far easier and more fluid way of specifying this UI. Taking a more strict approach to using MVVM meant we could unit test the view models. This gave us more reliability for what would happen in the UI.
MVVM still uses WPF binding, however, and issues still arise in this area. We wanted to be able to test this and be sure that what we say should happen on the UI actually does happen. After a little bit of effort we found that given our new structure and architecture we could test each UI component individually using specs and then test them all together. This is much like we have with the activities and the composition specs.
The new spec:
Scenario: Creating And Deleting Folder and Popup says cancel in localhost Given the explorer is visible When I open "localhost" server Then I should see "5" folders When I add "MyOtherNewFolder" in "localhost" Then I should see the path "localhost/MyOtherNewFolder" And I should see "6" folders And I choose to "Cancel" Any Popup Messages Then I should see "6" folders When I open "Folder 2" Then I should see "18" children for "Folder 2" When I create "localhost/Folder 2/myNewFolder" Then I should see "19" children for "Folder 2" Then I should see the path "localhost/Folder 2/myNewFolder" And I choose to "OK" Any Popup Messages When I delete "localhost/Folder 2/myNewFolder" Then I should see "18" children for "Folder 2" Then I should not see the path "localhost/Folder 2/myNewFolder"
As you can see this kind of spec is far easier to read and actually makes far more sense. What is really cool is that this spec actually executes against the UI as if it were shown to the user. It is an absolutely true reflection of what would happen when the above actions are performed. Another advantage is that these new specs run in a fraction of the time as the previous ones.
Last words on testing using SpecFlow for Warewolf
It has been really fun writing this series and even more fun exploring and extending our use of SpecFlow. I hope that these posts have been useful and informative. Again I direct you to the Warewolf open source project to get intimate details of how these specs are working and executing. I encourage you to write a few of your own.
Leave A Comment?