Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à BDD Visual Studio SpecFlow Watin
Similaire à BDD Visual Studio SpecFlow Watin (20)
Dernier
Dernier (20)
BDD Visual Studio SpecFlow Watin
- 1. BDD WITH VISUAL STUDIO 2010, SPECFLOW AND WATIN CHARLES NURSE SENIOR ARCHITECT, DOTNETNUKE CORP. CHARLES.NURSE@DNNCORP.COM @CNURSE DotNetNuke Corp. Confidential © 2011 All rights reserved.
- 2. AGENDA • Intro to BDD • Gherkins • SpecFlow • WatiN • Demos DotNetNuke Corp. Confidential © 2011 All rights reserved. 2
- 3. PART I – BEHAVIOR DRIVEN DEVELOPMENT • Developed by Dan North • Response to some issues with TDD » Where to start » What to test and what not to test » How much to test in one go » What to call the tests » How to understand why a test fails BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. Dan North DotNetNuke Corp. Confidential © 2011 All rights reserved. 3
- 4. PART I – BEHAVIOR DRIVEN DEVELOPMENT • Driven by Business Value • Realized through the Interface (GUI) • Tests are defined in a natural language (Gherkins) DotNetNuke Corp. Confidential © 2011 All rights reserved. 4
- 5. PART I – BEHAVIOR DRIVEN DEVELOPMENT • BDD Practices » Establish the goals of different stakeholders » Drawing out features which will achieve those goals using feature injection » Involve stakeholders through outside–in software development » Use examples to describe the behavior of the application » Automate those examples to provide feedback and regression testing » Use 'should' when describing the behavior of software » Use 'ensure' when describing responsibilities of software » Use mocks to stand-in for modules of code which have not yet been written DotNetNuke Corp. Confidential © 2011 All rights reserved. 5
- 6. PART 2 – GHERKINS • Natural Language definition of tests. » TDD – Arrange, Act, Assert • Gherkin – Given, When, Then » Given – defines the conditions that must exits for the test to be run » When – defines the action a “user” will execute » Then – defines the expectations of the Test • Gherkins Frameworks » Cucumber – Ruby » Lettuce – Python » Specflow - .NET DotNetNuke Corp. Confidential © 2011 All rights reserved. 6
- 7. PART 2 – GHERKINS • Example – "Refunded or exchanged items should be returned to stock.“ • Customer, Product Manager, Developer or QA engineer might clarify the requirements by breaking this down into specific scenarios • Scenario 1: Refunded items should be returned to stock • Scenario 2: Replaced items should be returned to stock DotNetNuke Corp. Confidential © 2011 All rights reserved. 7
- 8. PART 2 – GHERKINS • Scenario 1: Refunded items should be returned to stock » Given a customer previously bought a black sweater from me » and I currently have three black sweaters left in stock » When he returns the sweater for a refund » Then I should have four black sweaters in stock DotNetNuke Corp. Confidential © 2011 All rights reserved. 8
- 9. PART 2 – GHERKINS • Scenario 2: Replaced items should be returned to stock » Given that a customer buys a blue garment » and I have two blue garments in stock » and three black garments in stock. » When he returns the garment for a replacement in black, » Then I should have three blue garments in stock » and two black garments in stock DotNetNuke Corp. Confidential © 2011 All rights reserved. 9
- 10. PART 2 – GHERKINS • Programmer-domain examples • Example 1: New lists are empty » Given a new list » Then the list should be empty • Example 2: Lists with things in them are not empty » Given a new list » When we add an object » Then the list should not be empty DotNetNuke Corp. Confidential © 2011 All rights reserved. 10
- 11. PART 3 – SPECFLOW • SpecFlow aims at bridging the communication gap between domain experts and developers by binding business readable behavior specifications to the underlying implementation. SpecFlow.org • Visual Studio Extension – to support Gherkin language tests » www.specflow.org » https://github.com/techtalk/SpecFlow • SpecFlow Demo DotNetNuke Corp. Confidential © 2011 All rights reserved. 11
- 12. PART 3 – SPECFLOW • Demo Summary • Review of SpecFlow in VS 2010 » Reviewed the Extension Manager Addin » Reviewed the Nuget Package (SpecFlow/NUnit) integration) » Added a SpecFlow Feature » Run SpecFlow Scenarios » Added Steps File » Updated Feature » Updated Steps File DotNetNuke Corp. Confidential © 2011 All rights reserved. 12
- 13. PART 4 – WATIN • Browser Automation Framework » Web Application Testing in .NET » http://watin.org/ • Inspired by WatiR (Web Application Testing in Ruby) • Supports IE (6+) or Firefox (2+) • Licensed under Apache License 2.0 • Available as a Nuget package DotNetNuke Corp. Confidential © 2011 All rights reserved. 13
- 14. PART 4 – WATIN • Automate all major HTML elements with ease • Find elements by multiple attributes • Native support for Page and Control model. • Supports AJAX website testing • Supports creating screenshots of webpages • Supports frames (cross domain) and IFrames DotNetNuke Corp. Confidential © 2011 All rights reserved. 14
- 15. PART 4 – WATIN • Handles popup dialogs like alert, confirm, login etc.. • Supports HTML dialogs (modal and modeless) • Easy to integrate with your favorite (unit) test tool • Can be used with any .Net Language • Downloaded more than 120,000 times. • Since its open source you can add/contribute new features yourself! DotNetNuke Corp. Confidential © 2011 All rights reserved. 15
- 16. PART 4 – WATIN • Finish the Tests DotNetNuke Corp. Confidential © 2011 All rights reserved. 16
- 17. PART 4 – WATIN • Demo Summary • Review of SpecFlow in VS 2010 » Reviewed the Nuget Package (WatiN) integration) » Completed the SpecFlow Scenario » Added a second SpecFlow Scenario » Reviewed a real Scenario in a real Application DotNetNuke Corp. Confidential © 2011 All rights reserved. 17
- 18. THANK YOU • For more info: » www.specflow.org » https://github.com/techtalk/SpecFlow » http://watin.org/ » www.dotnetnuke.com • Feedback » https://www.surveymonkey.com/s/GHLYGSS • Email: charles.nurse@dnncorp.com • Blog: www.charlesnurse.com • Twitter: @cnurse DotNetNuke Corp. Confidential © 2011 All rights reserved. 18
Notes de l'éditeur
- http://en.wikipedia.org/wiki/Behavior_Driven_Developmenthttp://behaviour-driven.org/
- BDD is driven by business value[6]; that is, the benefit to the business which accrues once the application is in production. The only way in which this benefit can be realized is through the user interface(s) to the application, usually (but not always) a GUI.In the same way, each piece of code, starting with the UI, can be considered a stakeholder of the other modules of code which it uses. Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.The first piece of production code that BDD developers implement is the UI. Developers can then benefit from quick feedback as to whether the UI looks and behaves appropriately. Through code, and using principles of good design and refactoring, developers discover collaborators of the UI, and of every unit of code thereafter. This helps them adhere to the principle of YAGNI, since each piece of production code is required either by the business, or by another piece of code already written.BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read. Behavior-driven developers use their native language in combination with the ubiquitous language of domain-driven design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc
- Establishing the goals of different stakeholders required for a vision to be implementedDrawing out features which will achieve those goals using feature injectionInvolving stakeholders in the implementation process through outside–in software developmentUsing examples to describe the behavior of the application, or of units of codeAutomating those examples to provide quick feedback and regression testingUsing 'should' when describing the behavior of software to help clarify responsibility and allow the software's functionality to be questionedUsing 'ensure' when describing responsibilities of software to differentiate outcomes in the scope of the code in question from side-effects of other elements of code.Using mocks to stand-in for collaborating modules of code which have not yet been written