Presented by Eugeny Govako Overview Gherkin and test automation NUnit based automation approach SpecFlow automation approach SpecFlow automation evolution QampA Gherkin and test automation ID: 1038714
Download Presentation The PPT/PDF document "UI Test Automation with SpecFlow" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1. UI Test Automation with SpecFlowPresented by Eugeny Govako
2. OverviewGherkin and test automationNUnit based automation approachSpecFlow automation approachSpecFlow automation evolutionQ&A
3. Gherkin and test automationTest Automation is implementing specifications step by step using some programming languageGherkin is the language for executable specificationsGherkin itself is a kind of a programming language with well defined syntaxOriginally invented to use with Cucumber framework
4. PrerequisitesGherkinSpecifications (written in Gherkin preferably)Test APIDriver providing access to Application with ability to find required controlWrappers for controlsApplication under testTestTestAPIApplication
5. Non-SpecFlow automationNUnit tests implementation based on Gherkin lines
6. Non-SpecFlow automation summaryGherkinNo direct link between specification (Gherkin) and test codeTest code uses Test API layer that provides access to controls, allowing application interaction
7. SpecFlow automation Specification linked to test Test development is very fast Automation code base grows even more fast Test Support trouble
8. SpecFlow automation: basicsUsing parameters to reduce code amount
9. SpecFlow automation: basicsTables can be used row-by-row
10. SpecFlow automation summaryTests code is directly connected to Gherkin via SpecFlow runnerTest API layer still used for providing controlsBinding method arguments reduce code amountParameters
11. Gherkin requirements for automationReuse stepsUse parameterization where possibleAny Gherkin line can be automated. However, there’s always tradeoff between effort needed to create scenario and effort needed to automate.
12. SpecFlow automation: advanced featuresUsing step argument transformations
13. Tables can be used in transformationsTables can be converted to parameter mapsSpecFlow automation: advanced features
14. Trouble? Parameterization leads to huge maps of controlsConflicting Regex for same actions in different contextsCode base still grows fastHow? Execution Context – specify where to look for controlUse direct transformations to automation wrappersRegister controls with friendly names in a context-specific resolverSilver Bullet?Makes it possible to have bindings provided from the box, along with control wrappersSpecFlow automation: generic approach
15. Example: working with buttonsIButton wrapperProvides access to Visibility, enabled state, text, click functionalityImplementation comes from automation frameworkVisual Resolver:Allows registering button by friendly nameAllows resolving button in an active contextAutomatically transforms control requested by friendly to DSL interface used inside binding methodStepArgumentTransformation returning IButtonUsing Visual Resolver, convert friendly name (string) into IButton wrapper instanceButton Bindings extending ControlBindingBase<IButton>Contain bindings that use string -> IButton conversionSpecFlow automation: control-based
16. Visual Resolver exampleSpecFlow automation: control-based
17. Control binding class exampleSpecFlow automation: control-based
18. Uses SpecFlow native step interpreterUses Regexp for steps and parameters mappingUses Visual Resolver to convert names to DSLControl-based approach: summaryReduced number of stepsDevelopment costs are lowDiagnostics is not goodSimilar steps still exist for different control types
19. Control based example:SpecFlow automation: behavior driven4 binding methodsScenarioBlockControl friendly nameControl typeWhat to checkBehavior driven exampleWHATHOWControl wrapper from Visual ResolverBehavior control should implement
20. Behavior-driven approachBehaviorInterfacePropertyshown / not shownICanBeVisibleIsVisibleenabled / disabledICanBeEnabledIsEnabledhas “some” textIHasVisibleTextTextWorks with all controls supporting behaviors designated by atomic interfacesNew behaviors can be introduced easily
21. Behavior driven approach: conclusionAutomation bindings number significantly reducedFocus on behavior, not control (closer to business)Still risks of conflicts hard to resolve via regexp
22. Romashka DriverGive up Regexp!Use smart step parser and grammar rulesFind controls and analyze/apply behaviorsNo Regexp conflictsNew behaviors added easilySupport new controls by applying behavior interfaces to DSLDiagnostics is even worseHard to understand and contributeCrush a fly upon a wheel feeling
23. Specflow automation in Autobahn FX UI100% P1 / 80% all automation coverage (of possible to automate) in 5 projects using SpecFlow More than 23000 test cases automatedReasonable test support costs
24. Q&A