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