For internal use only UI Test Automation with SpecFlow Presented by Eugeny Govako
For internal use only Overview Gherkin and test automation NUnit based automation approach SpecFlow automation approach SpecFlow automation evolution Q&A
For internal use only Gherkin and test automation Test Automation is implementing specifications step by step using some programming language Gherkin is the language for executable specifications Gherkin itself is a kind of a programming language with well defined syntax Originally invented to use with Cucumber framework
For internal use only Prerequisites Gherkin Specifications (written in Gherkin preferably) Test API Driver providing access to Application with ability to find required control Wrappers for controls Application under test Test TestAPI Application
For internal use only Non-SpecFlow automation NUnit tests implementation based on Gherkin lines
For internal use only Non-SpecFlow automation summary Test TestAPI Application Gherkin No direct link between specification (Gherkin) and test code Test code uses Test API layer that provides access to controls, allowing application interaction
For internal use only SpecFlow automation Specification linked to test Test development is very fast Automation code base grows even more fast Test Support trouble
For internal use only SpecFlow automation: basics Using parameters to reduce code amount
For internal use only SpecFlow automation: basics Tables can be used row-by-row
For internal use only SpecFlow automation summary Gherkin SpecFlow engine Bindings Test API Application Tests code is directly connected to Gherkin via SpecFlow runner Test API layer still used for providing controls Binding method arguments reduce code amount Parameters
For internal use only Gherkin requirements for automation Reuse steps Use parameterization where possible Any Gherkin line can be automated. However, there’s always tradeoff between effort needed to create scenario and effort needed to automate.
For internal use only SpecFlow automation: advanced features Using step argument transformations
For internal use only Tables can be used in transformations Tables can be converted to parameter maps SpecFlow automation: advanced features
For internal use only Trouble? Parameterization leads to huge maps of controls Conflicting Regex for same actions in different contexts Code base still grows fast How? Execution Context – specify where to look for control Use direct transformations to automation wrappers Register controls with friendly names in a context-specific resolver Silver Bullet? Makes it possible to have bindings provided from the box, along with control wrappers SpecFlow automation: generic approach
For internal use only Example: working with buttons IButton wrapper Provides access to Visibility, enabled state, text, click functionality Implementation comes from automation framework Visual Resolver: Allows registering button by friendly name Allows resolving button in an active context Automatically transforms control requested by friendly to DSL interface used inside binding method StepArgumentTransformation returning IButton Using Visual Resolver, convert friendly name (string) into IButton wrapper instance Button Bindings extending ControlBindingBase<IButton> Contain bindings that use string -> IButton conversion SpecFlow automation: control-based
For internal use only Visual Resolver example SpecFlow automation: control-based
For internal use only Control binding class example SpecFlow automation: control-based