2. Agenda
• Part I: AAT Overview
• Part II: Pros & Cons of AAT
• Part III: AAT Tools and Syntax in .NET
• Part IV: Overcoming the Cons of AAT
• Part V: Demo
15. Communication
• Helps specify behavior of the system in plain text
• Provides a medium for non-tech and devs to agree on
Are we
talking
about
the right
system?
20. Why NOT have ATTs?
• Business users won‟t write specifications
• Brittle and slow
• High false negatives, non-determinism
“Certainly it is not necessary to run every
example to be sure that the code works.
Probably it is necessary to run some.”
– Ron Jeffries
30. Start with a story
User story
As an internet user,
I want to search for “ALT.NET”
And get valid results
• Acceptance criteria 1: I get at least 100k results
• Acceptance criteria 2: Results ordered by relevance
…
Scenarios
Feature
31. Gherkin in a SpecFlow feature
Feature: Google Search
As an internet user
I want to search for “ALT.NET”
So that I can be knowledgeable about the organzation
Background: I am logged into my Google account
Scenario: Search for „ALT.NET‟
Given I am on the Google Home Page
When I search for ”ALT.NET"
Then I should see at least 100,000 results
And the results should be ordered by relevance
Step
32. Generate Step Definitions
[When(@"I search for ""(.+)""")]
public void WhenISearchForSomething(string searchTerm)
{
GoogleSearchResultsPage = GoogleHomePage.Search(searchTerm);
}
Step Definition
40. Minimize # of end-to-end tests
• AATs for journeys, not stories
• Is your new story entirely new?
• Balance high # of unit tests + selected end-to-end &
acceptance
41. Page Objects
public class GoogleHomepage: PageBase, IGoogleHomepage {
// Flow for this page
}
GoogleHomepage
+search(query)
+clickSearch()
+clickGettingLucky
43. public class GoogleHomepage: PageBase, IGoogleHomepage {
// Flow for this page
}
Domain
Service
UI
GoogleHomepage
+search(query)
+clickSearch()
+clickGettingLucky Data Access
GoogleHomepageService
+search(query)
+clickSearch()
+clickGettingLucky
IGoogleHomepage
+search(query)
+clickSearch()
+clickGettingLucky
44. Concise Specs
• Declarative
• Reuse steps
• Concise, many methods, fat fixtures
Bad:
• Click on Log In button
• Click username box and type „myUsername‟ and click „password‟ box and type
„myPassword‟
• Click on link for Transfer Payment
• Click box for amount and type 400
• Click „Transfer‟ button
• Assert success message
Good:
• Login as „MyAccountName‟
• Navigate to Transfer Payment page
• Transfer 400 dollars
• Assert success message
49. Developer tips
• Don't run in same assembly as other tests, so these can
be run separately since they're very slow (i.e. nightly)
• Navigation
• Haywire! Sometimes when moving step definitions
around, the gherkin gets confused and can‟t find the
target. Restart VS.
51. Gherkin
• Describe what, not how (Don‟t: „Click the Log In button‟. Do:
„Navigate to the log in screen‟)
• Specs shouldn‟t have much setup code
Given I am on the homepage
And I click login
And I enter username of „username‟ and password of „password‟
When clicking „Log In‟
Then take me to my landing page
Given I am on the homepage
When logging in with „username‟ and „password‟
Then take me to my landing page
52. Scenario Outline
Parameterize!
Scenario: eat 5 out of 12
Given there are 12 cucumbers
When I eat 5 cucumbers
Then I should have 7 cucumbers
Scenario: eat 5 out of 20
Given there are 20 cucumbers
When I eat 5 cucumbers
Then I should have 15 cucumbers
53. Scenario Outline
Parameterize!
Scenario Outline: eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
54. Parameters
Given I entered the following data into the new account form:
| Field | Value |
| Name | John Galt |
| Birthdate | 2/2/1902 |
| HeightInInches | 72 |
| BankAccountBalance | 1234.56 |
or in a horizontal table like this:
| Name | Birthdate | HeightInInches | BankAccountBalance |
| John Galt | 2/2/1902 | 72 | 1234.56 |
| John Doe | 1/1/1980 | 68 | 1111.99 |
55. UI tests
• Sometimes tests will fail if the page doesn‟t have enough
time to load. Use implicit waits, and explicit when really
needed
• Capture screen shots when tests fail
• Selenium IDE
56. Anti-patterns
• Developers writing acceptance tests by themselves, for
themselves
• Tying AATs to an implementation - unit tests are
implementation specific, AATs are NOT
• Too much repetition in the gherkin
• Too many UI tests
Bad legacy code in mission critical system, not unit testable…Useful in general in a test suite for many reasons…
AcceptanceTestsFits their requirements. The story is complete. Automated
Readable by whole spectrum
What kind of tests do you run with your specs?UI – smoke, sanity, UI goo Functionality – Integration testsRun close to production; like a user would.
Mostly unit testsHARD to maintain, slow SO….
Unit test everything thru JavaScriptMost RELEVANT test cases for AATs (can’t hit all alt paths)Shouldn’t manually regression test
Whoever writes user storiesDev/Tester/BA BEFORE iteration starts
-Communication with business stakeholders, BAs, QA
-Unit tests don’t account for everything, seams-Gaps in coverage, unit tests not hitting right test cases,
-Full regression doesn’t always happen-Manual testing lapseMistakes in testing, non-testing, non-regressingAllow testers to do more exploratory and higher level things, less boring
Bugs will be caught earlier
Not doing, btw
Some have even said it’s not worth the cost
Create a spec in gherkinGerkin is a line-oriented language (line step)In SpecFlow, Generate step definitionsIn Selenium & NUnit, write UI/integration tests to power the AATs
All know definition of User Story? Should be turned into specs before iteration starts (bus & )
Given – set up the context of your testWhen – action performed by userThen - asserts