|
1 |
| -# Basics of Cucumber |
2 |
| - |
3 |
| -Starting with two example Feature Files... |
4 |
| - |
5 |
| -## example1.feature |
6 |
| -``` |
7 |
| -Feature: Login Functionality Feature |
8 |
| -
|
9 |
| - In order to ensure Login Functionality works, |
10 |
| - I want to run the Cucumber test to verify it is working |
11 |
| -
|
12 |
| -Scenario: Login Functionality |
13 |
| -
|
14 |
| - Given user navigates to SOFTWARETESTINGHELP.COM |
15 |
| - When user logins in using Username as "USER" and Password "PASSWORD" |
16 |
| - Then login should be successful |
17 |
| -
|
18 |
| -Scenario: Login Functionality |
19 |
| -
|
20 |
| - Given user navigates to SOFTWARETESTINGHELP.COM |
21 |
| - When user logins in using Username as "USER" and Password "PASSWORD1" |
22 |
| - Then error message should be thrown |
23 |
| -``` |
24 |
| - |
25 |
| -## example2.feature |
26 |
| -``` |
27 |
| -Background: |
28 |
| -
|
29 |
| - Given user logged in as databases administrator |
30 |
| - And all the junk values are cleared |
31 |
| -
|
32 |
| -Feature: Login Functionality Feature |
33 |
| -
|
34 |
| -Scenario: Login Functionality |
35 |
| -
|
36 |
| - Given user navigates to SOFTWARETETINGHELP.COM |
37 |
| - When user logs in using Username as “USER” |
38 |
| - And password as “password” |
39 |
| - Then login should be successful |
40 |
| - And Home page should be displayed |
41 |
| -``` |
42 |
| - |
43 |
| -## Feature Files |
44 |
| -- End with .feature extension |
45 |
| -- Essential to Cucumber |
46 |
| -- Used to write test automation steps or acceptance tests |
47 |
| -- Can be used as "live documents" |
48 |
| -- The steps are the application spec |
49 |
| - |
50 |
| -## Features |
51 |
| -- The high-level business functionality and purpose of application under test |
52 |
| -- Reading the first Feature should make the intent of the Feature File clear |
53 |
| - |
54 |
| -## Scenarios |
55 |
| -- A particular functionality under test |
56 |
| -- Follows "given, when, then" format (Gherkin syntax) |
57 |
| - - **Given** specifies pre-conditions, it is a known state |
58 |
| - - **When** is used when some action is to be performed |
59 |
| - - **Then** is the expected outcome or result |
60 |
| - - **Background** is for any step required to perform each scenario, i.e. clear a database before each scenario |
61 |
| - - **And** is used to combine two or more actions of the same type |
62 |
| - |
63 |
| -## Scenario Outlines |
64 |
| -- Used when same test has to be performed with multiple sets of data |
65 |
| -- Replace "Scenario" with "Scenario Outline" |
66 |
| -- "Examples" are used to pass different arguments in tabular format |
67 |
| - |
68 |
| -``` |
69 |
| -Feature: Login Functionality Feature |
70 |
| -
|
71 |
| - In order to ensure Login Functionality works, |
72 |
| - I want to run the cucumber test to verify it is working |
73 |
| -
|
74 |
| -Scenario Outline: |
75 |
| -
|
76 |
| - Given user navigates to SOFTWARETESTINGHELP.COM |
77 |
| - When user logs in using Username as <username> and Password <password> |
78 |
| - Then login should be successful |
79 |
| -
|
80 |
| -Examples: |
81 |
| - |username |password | |
82 |
| - |Tom |password1 | |
83 |
| - |Harry |password2 | |
84 |
| - |Jerry |password3 | |
85 |
| -``` |
86 |
| - |
87 |
| -## Tags |
88 |
| - |
89 |
| -- By default Cucumber runs all scenarios in all feature files |
90 |
| -- Specifying tags gives you something to filter by so as not to run hundreds of feature files at all times |
91 |
| -- Tags can be at the Feature level or Scenario level |
92 |
| - |
93 |
| -``` |
94 |
| -@SmokeTest @LoginTest |
95 |
| -
|
96 |
| -Feature: Login Functionality Feature |
97 |
| -
|
98 |
| - In order to ensure Login Functionality works, |
99 |
| - I want to run the cucumber test to verify it is working |
100 |
| -
|
101 |
| -Scenario Outline: Login Functionality |
102 |
| -
|
103 |
| -... |
104 |
| -
|
105 |
| -@positiveScenario |
106 |
| -Scenario: Login Functionality |
107 |
| -
|
108 |
| -... |
109 |
| -``` |
110 |
| - |
111 |
| -## JUnit Runner |
112 |
| - |
113 |
| -- Cucumber uses a standard JUnit runner |
114 |
| -- Tags get specified in @Cucumber.Options |
115 |
| -- Multiple tags get specified with commas as delimiters |
116 |
| -- Can also specify the path and type of report |
117 |
| - |
118 |
| -``` |
119 |
| -import cucumber.api.junit.Cucumber; |
120 |
| -import org.junit.runner.RunWith; |
121 |
| -
|
122 |
| -@RunWith(Cucumber.class) |
123 |
| -@Cucumber.Options(format={"SimpleHtmlReport:report/smokeTest.html"}, tags={"@SmokeTest"}) |
124 |
| -Public class JUnitRunner { ... } |
125 |
| -``` |
126 |
| - |
127 |
| -## Cucumber Reporting |
128 |
| -- By default this is generated in Cucumber's own HTML format |
129 |
| -- Better reporting can be done, for example using Jenkins or Bamboo |
| 1 | + |
| 2 | +# Basics of Cucumber |
| 3 | + |
| 4 | +Cucumber is a framework for writing tests in the style of "behavior-driven development" (BDD). |
| 5 | + |
| 6 | +There will be two parts to tests this way -- **feature files** and **step definitions**. |
| 7 | + |
| 8 | +Let's start by taking a look at two example feature files below. |
| 9 | + |
| 10 | +## example1.feature |
| 11 | + |
| 12 | +``` |
| 13 | +Feature: Login Functionality Feature |
| 14 | +
|
| 15 | + In order to ensure Login Functionality works, |
| 16 | + I want to run the Cucumber test to verify it is working |
| 17 | +
|
| 18 | +Scenario: Login Functionality |
| 19 | +
|
| 20 | + Given user navigates to SOFTWARETESTINGHELP.COM |
| 21 | + When user logins in using Username as "USER" and Password "PASSWORD" |
| 22 | + Then login should be successful |
| 23 | +
|
| 24 | +Scenario: Login Functionality |
| 25 | +
|
| 26 | + Given user navigates to SOFTWARETESTINGHELP.COM |
| 27 | + When user logins in using Username as "USER" and Password "PASSWORD1" |
| 28 | + Then error message should be thrown |
| 29 | +``` |
| 30 | + |
| 31 | +## example2.feature |
| 32 | + |
| 33 | +``` |
| 34 | +Background: |
| 35 | +
|
| 36 | + Given user logged in as databases administrator |
| 37 | + And all the junk values are cleared |
| 38 | +
|
| 39 | +Feature: Login Functionality Feature |
| 40 | +
|
| 41 | +Scenario: Login Functionality |
| 42 | +
|
| 43 | + Given user navigates to SOFTWARETETINGHELP.COM |
| 44 | + When user logs in using Username as “USER” |
| 45 | + And password as “password” |
| 46 | + Then login should be successful |
| 47 | + And Home page should be displayed |
| 48 | +``` |
| 49 | + |
| 50 | +## Feature files |
| 51 | + |
| 52 | +- End with .feature extension |
| 53 | +- Essential to Cucumber |
| 54 | +- Used to write test automation steps or acceptance tests |
| 55 | +- Can be used as "live documents" |
| 56 | +- The steps are the application spec |
| 57 | + |
| 58 | +## Features |
| 59 | + |
| 60 | +- The high-level business functionality and purpose of application under test |
| 61 | +- Reading the first Feature should make the intent of the Feature File clear |
| 62 | + |
| 63 | +## Scenarios |
| 64 | + |
| 65 | +- A particular functionality under test |
| 66 | +- Follows "given, when, then" format (Gherkin syntax) |
| 67 | + - **Given** specifies pre-conditions, it is a known state |
| 68 | + - **When** is used when some action is to be performed |
| 69 | + - **Then** is the expected outcome or result |
| 70 | + - **Background** is for any step required to perform each scenario, i.e. clear a database before each scenario |
| 71 | + - **And** is used to combine two or more actions of the same type |
| 72 | + |
| 73 | +## Scenario outlines |
| 74 | + |
| 75 | +- Used when same test has to be performed with multiple sets of data |
| 76 | +- Replace "Scenario" with "Scenario Outline" |
| 77 | +- "Examples" are used to pass different arguments in tabular format |
| 78 | + |
| 79 | +``` |
| 80 | +Feature: Login Functionality Feature |
| 81 | +
|
| 82 | + In order to ensure Login Functionality works, |
| 83 | + I want to run the cucumber test to verify it is working |
| 84 | +
|
| 85 | +Scenario Outline: |
| 86 | +
|
| 87 | + Given user navigates to SOFTWARETESTINGHELP.COM |
| 88 | + When user logs in using Username as <username> and Password <password> |
| 89 | + Then login should be successful |
| 90 | +
|
| 91 | +Examples: |
| 92 | + |username |password | |
| 93 | + |Tom |password1 | |
| 94 | + |Harry |password2 | |
| 95 | + |Jerry |password3 | |
| 96 | +``` |
| 97 | + |
| 98 | +## Tags |
| 99 | + |
| 100 | +- By default Cucumber runs all scenarios in all feature files |
| 101 | +- Specifying tags gives you something to filter by so as not to run hundreds of feature files at all times |
| 102 | +- Tags can be at the Feature level or Scenario level |
| 103 | + |
| 104 | +``` |
| 105 | +@SmokeTest @LoginTest |
| 106 | +
|
| 107 | +Feature: Login Functionality Feature |
| 108 | +
|
| 109 | + In order to ensure Login Functionality works, |
| 110 | + I want to run the cucumber test to verify it is working |
| 111 | +
|
| 112 | +Scenario Outline: Login Functionality |
| 113 | +
|
| 114 | +... |
| 115 | +
|
| 116 | +@positiveScenario |
| 117 | +Scenario: Login Functionality |
| 118 | +
|
| 119 | +... |
| 120 | +``` |
| 121 | + |
| 122 | +## JUnit runner |
| 123 | + |
| 124 | +Just having **feature files** and **step definitions** isn't enough to have these sorts of tests run with your normal suite. |
| 125 | + |
| 126 | +In Java, we typically get this Cucumber stuff to run using a JUnit runner. |
| 127 | + |
| 128 | +- Tags get specified in @Cucumber.Options |
| 129 | +- Multiple tags get specified with commas as delimiters |
| 130 | +- Can also specify the path and type of report |
| 131 | + |
| 132 | +``` |
| 133 | +import cucumber.api.junit.Cucumber; |
| 134 | +import org.junit.runner.RunWith; |
| 135 | +
|
| 136 | +@RunWith(Cucumber.class) |
| 137 | +@Cucumber.Options(format={"SimpleHtmlReport:report/smokeTest.html"}, tags={"@SmokeTest"}) |
| 138 | +Public class JUnitRunner { ... } |
| 139 | +``` |
| 140 | + |
| 141 | +## Cucumber reporting |
| 142 | + |
| 143 | +- By default this is generated in Cucumber's own HTML format |
| 144 | +- Better reporting can be done, for example using Jenkins or Bamboo |
0 commit comments