Forum 2.0

Replies

  • Gherkin is a language for describing business behavior without creating detailed implementations. Top software testing companies structure the scenarios as per their “Context”, “Action” and “Outcome”.
    The scenarios are created using simple English language explaining the way a feature should behave as per the given situation.
    The Gherkin test cases are created in feature files with an extension .feature and these are readable by BDD supported tools e.g., cucumber, Behat, etc.

     

    Below are the best practices for writing Gherkin test cases:

    • The feature file starts with the Feature which is actually the story. There should have at least one liner scenario describing the activity or acceptance criteria of feature file.
    • The story should be simplified and should specify the reason for its requirement.
    • Related test scenarios should be added to the same feature file once after the feature is defined.
    • Multiple scenarios defined in the same feature file should be independent of each other so that they could be individually run.
    • The scenarios should be followed-up with the Given, Event and Result. The Gherkin defines these steps using the keywords “Given”, “When” and “Then”.
    • The “Given” should not define anything other than the pre-requisites for the scenarios.
    • “When” defines the actions performed in scenario to accomplish the result.
    • The validation point or checkpoint for the expected result is declared in “Then”.
    • Always use “AND” to declare multiple checkpoints or events/actions between “Given”, “When” and “Then”.
    • Implementation of tags in “Feature” or “Scenario” using @ for increasing the code reusability at scenario level or feature level.
      For e.g., Functionality: @TestModule1 @TestModule2, Purpose of Test: @regressionTest  @smoketest
    • Use Background as best practices: In case, the same setup steps are required for all the scenarios in a feature file then use “Background”.
      Cucumber executes the Background before every scenario declared in the feature file.

     

    Please refer example below:

     

    Background:

    Given the following user exists

    | First Name | Last Name | Is SystemAdmin |CSV file|

    | User | A | true |Test CSV |Test Doc |

    And the CSV "Test CSV" file have valid data

    And "User A" is logged in

    And the user is on the "System" page

     

    @TestModule1
    Scenario: Verification of uploaded data

    When the user clicks the "Upload"

    And the user selects "Option1" from the "detailed" drop down

    And the user clicks "Choose File" and the user select "Test CSV"

    Then the user should see name under the "Name" column

    And the user should see type under the "Type" column

    And the user should see Owner Email under the "Owner Email" column

    And the user should see Errors under “Invalid” column

     

    The Best Software Testing Services Company - QASource
    Partner with the leading software testing company, QASource, and accomplish all your software testing goals within strict deadlines and budget. We pr…
This reply was deleted.
    results->result as $result) { ?>
  1. jobtitle;?>
    company;?>(formattedRelativeTime;?>)city;?>, state;?>

    APPIUM

    Blockchain Testing

    Welcome to Mobile QA Zone, a Next Generation Software Testing Community.Invite your friends to join this community.Write to us to become a featured member.