Skip to content
QiTASC.com / General Concepts / Feature Files /
Introduction
/ .. / .. /
Introduction










Feature Files

A Feature File is a set of one or more Scenarios or Scenario Outlines that builds the general outline of a test case. It contains a structured set of Steps and/or Compound Steps.

Important! A Feature File must contain either Scenarios or Scenario Outlines. Combining Scenarios and Scenario Outlines in the same Feature File will cause the test case to fail.

Every file with the extension .feature consists of a single Feature, which defines the test scope. The Feature: <featureName> must be specified at the top of the file, above the first Scenario or Scenario Outline. Only specify the Feature: <featureName> keyword once, even if a Feature File contains multiple Scenarios. Specifying it multiple times in the same file will cause the test to fail.

To create a Feature File, select File -> New -> Feature or File -> New -> Feature with Scenario Outline in intaQt Studio.

Syntax 

1
Feature: <featureName Identifier>

Parameter

  • FeatureName - The name assigned to the Feature File

Example 

1
Feature: Phones

Feature with Scenario

A Scenario defines all the steps in a Feature File, line-by-line, that will be executed.

Metadata may be added to Scenario Outlines.

Example 

1
2
3
4
Feature: Phones
  Scenario: Select specific phones
    Given an Android phone as A where network == "3G"
    Given an Android phone as B where network == "4G"

Create a Feature with Scenario

To create a Feature File with a Scenario, either:

  • Select File -> New -> Feature in intaQt Studio. This will create template for the Feature File with Scenario.

alt text

  • Alternately, type the Scenario: keyword in the row beneath the Feature keyword in an existing Feature File, and assign the Scenario a name.

Syntax 

1
2
Feature: Phones
  Scenario: <scenarioName Identifier>

Parameter

  • scenarioName - The name assigned to the Feature File

Example 

1
2
Feature: Phones
  Scenario: Select specific phones

Note:

  • While Scenario Outlines contain Examples, Scenarios do not. Including Examples in a Scenario will cause the test case to fail.

  • If Scenario Outline is written instead of Scenario, an error with the message No tests were found will occur because intaQt expects an Examples table in Feature Files with Scenario Outlines.

Feature with Scenario Outline

A Scenario Outline contains an Examples table, which is populated by defined variables. This Examples table is created at the bottom of the Scenario Outline. Scenario Outlines enable running a test case with different values for each iteration. For example, a Scenario Outline may be used in a test case that tests an applications behavior on different registered networks. Using a Scenario Outline reduces the amount of time required to write and maintain such tests.

Metadata may be added to Scenario Outlines.

Example 

1
2
3
4
5
6
7
8
9
Feature: Phones
  Scenario Outline: Selecting specific phones with scenario outline
  Given an Android phone as A where network == <network1>
  Given an Android phone as B where network == <network2>

  Examples:
    | network1 | network2 |
    | "3G"     | "2G"     |
    | "4G"     | "3G"     |

If an Examples table missing from the Scenario Outline, an error message stating No tests were found will appear.

Create a Feature with Scenario Outline

To create a Feature File with a Scenario Outline, either:

  • Select File -> New -> Feature with Scenario in intaQt Studio. This will create template for the Feature File with Scenario Outline.

alt text

  • Alternately, type the Scenario Outline: keyword in the row beneath the Feature keyword, and assign it a name.

Syntax 

1
2
Feature: Phones
  Scenario Outline: <scenarioOutlineName Identifier>

Parameter

  • scenarioOutlineName - The name assigned to the Scenario Outline

Example 

1
2
Feature: Phones
  Scenario Outline: Selecting specific phones with scenario outline

An Examples template will appear at the bottom of the Feature File:

alt text

The Scenario Outline Example table contains:

  • Columns for each variable. Each column is separated by a pipe character (|).

    • The first row of each column defines the name for each set of variables.

  • Rows for each variable value.

    • Any parameter type (for example, string, number, Context Object) may be used, but only one type per column is allowed.

Commenting Out and Test Descriptions

Lines of a Feature File may be commented out by typing the number sign (#) at the beginning of that row. These rows will not be evaluated as steps by intaQt.

Example 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
Scenario Outline: Voice_BasicCall
## This is a comment
  Given an Android phone as A
    And an Android phone as B
  When A dials the number <calledParty>
    And within 35 seconds, B detects an incoming call from A.number
    And after <ring> seconds, B answers the incoming call
    And within 5 seconds, A connects
    And after <dur> seconds, A ends the call and, within 10 seconds, he
        and B disconnect
Examples:
  | dur | ring | calledParty |
  | 10  |  3   | B.number     |
  | 10  |  5   | B.local      |

Commenting to the Log

Using #-> instead of the # character prints the comment to the intaQt logs.

Example 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Feature: CommentedFile

  #-> see my description

  Scenario: Comments

    # I am an invisible comment
    #-> I am a visible comment

    And wait for 2 seconds
    #-> I am a visible comment too
    And verify false

The example above will print the following to the logs:

alt text

Note:

  • If the #-> is in the last line of a Feature File, the comment will not be printed to the log.

  • If an unresolved stepdef follows the #->, the comment will not be printed to the log.

Test Case Descriptions

Test Case Descriptions are a variation of commented-out lines. By convention, Test Case Descriptions are placed between a Feature keyword and Scenario/Scenario Outline keyword by using the number sign (#) to comment out those rows. Additional information may be written within the commented-out block.

Example 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
Feature: FeatureName
################################################################################
#Title: TitleOfYourTestCase
#Prerequisites:
#  -  A-Party has a phone
#  -  B-Party has a phone
# OtherDetailsYouConsiderImportant
################################################################################

  Scenario Outline: Voice_BasicCall
    Given an Android phone as A
      And an Android phone as B
    When A dials the number <calledParty>
      And within 35 seconds, B detects an incoming call from A.number
      And after <ring> seconds, B answers the incoming call
      And within 5 seconds, A connects
      And after <dur> seconds, A ends the call and, within 10 seconds, he
          and B disconnect
  Examples:
    | dur | ring | calledParty |
    | 10  |  3   | B.number    |
    | 10  |  5   | B.local     |

Feature File Backgrounds

Backgrounds are useful when a Feature File contains multiple Scenarios that start with a shared context. Adding the Background keyword specifies the common steps that should always be run before each Scenario within a Feature.

Example with Feature File Backgrounds

The example below contains two Scenarios:

  • The first Scenario includes a voice call between two parties.

  • The second Scenario includes a call with a long duration.

  • A Background specifies that Phone A is registered to a 3G network and that Phone B is registered to a 4G network.

The steps specified in the Background will be executed prior to each Scenario execution: 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Feature: Phones

  Background:
    Given an Android phone as A where network == "3G"
    Given an Android phone as B where network == "4G"

# First Scenario
  Scenario: Compound Call

    And A starts a call to B as MYCALL:
      * detect incoming call within 10 seconds
      * call duration is 7 seconds
      * caller ends the call
      * caller connects within 5 seconds
      * callee connects within 5 seconds
      * caller dials nat format
      * callee expects signaled number in any format
      * ringing duration is 8 seconds

   And expect the call MYCALL to start ringing
   And expect the call MYCALL to connect
   And expect the call MYCALL to disconnect

# Second Scenario
  Scenario: Long Call Duration

    And A starts a call to B as MYCALL:
      * call duration is 2 minutes

    And expect the call MYCALL to connect
    And expect the call MYCALL to disconnect

Example Without Feature File Background

The example below contains two Scenarios:

  • The first Scenario includes a voice call between two parties.

  • The second Scenario includes a call with a long duration.

  • Each Scenario includes two steps at the beginning, which address the phones.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Feature: Phones

# First Scenario
  Scenario: Compound Call

    Given an Android phone as A where network == "3G"
    Given an Android phone as B where network == "4G"

    And A starts a call to B as MYCALL:
      * detect incoming call within 10 seconds
      * call duration is 7 seconds
      * caller ends the call
      * caller connects within 5 seconds
      * callee connects within 5 seconds
      * caller dials nat format
      * callee expects signaled number in any format
      * ringing duration is 8 seconds

   And expect the call MYCALL to start ringing
   And expect the call MYCALL to connect
   And expect the call MYCALL to disconnect

# Second Scenario

  Scenario: Long Call Duration

    Given an Android phone as A where network == "3G"
    Given an Android phone as B where network == "4G"

    And A starts a call to B as MYCALL:
      * call duration is 2 minutes

    And expect the call MYCALL to connect
    And expect the call MYCALL to disconnect