Description

This article provides a complete example for setting up a G-Data Table and using it to call GenRocket Components dynamically (e.g., Scenarios, Scenario Chains, Scenario Chain Sets, G-Cases) within a Cumber Test.


In This Article


Sample Story

A tester wants to create a feature file and implement a step definition to perform a load test on the genrocket_bank.user table. The user has determined that 1000 rows of data will be needed to effectively test the user table load. Thus, the tester will utilize GenRocket's Feature File platform to take advantage of G-Data Tables. Then, the step definition will generate the 1000 rows of user data it needs dynamically.


Step 1: Creating and Editing the Feature File

In this 1st image, the userLoadTesting feature has been created, its steps defined and the feature file text is visible within the Gherkin tab.



In this 2nd image, for the userLoadTesting feature, the step definition text is visible with the Step Definition tab. Note, the Step Definition used in this example is Groovy as opposed to Java.



This 3rd image shows the advantages of using the G-Data Table Editor to easily create and modify a G-Data Table.



In this 4th image, The G-Data Table Editor allows the user to quickly search and select different self-serve components that will be assembled into a Data Table. The G-Data Table defined will is mimicking the following GenRocket commands. 

  • Standard Commandline Version
    • genrocket -r UserScenario.grs -tdc BankTestCases.gtdc:Load.load1000
  • G-Repository Commandline Version
    • genrocket -grepo GenRocketBank -grs UserSceanrio -tdc BankTestCase.Load.load1000
  • Step Definition Version
    • GRFeatureFile.execute(arg1.asMaps(), false)



Step 2: Download the Feature File and Step Definition File

After setting up the Feature File, click on the Download (Cloud) icon to download the Feature File and Step Definition File. Users can download both files or use the checkboxes to select or deselect files.



The Feature File will appear as shown below once downloaded (or copied). The 'profileId' is automatically added to the feature file by GenRocket.


Feature: Users Load Testing

  Scenario: Load users
    Given the count
    When users are loaded
      | Scenario     | G-CaseSuite   | G-Category | G-Case   | profileId |
      | UserScenario | BankTestCases | Load       | load1000 | GR5285237 |
    Then user count is increased by one thousand
    And users are deleted


Step 3: Modify the Step Definition File

The example code defined below is written in Groovy and is merely one of an infinite number of ways this code could have been written to execute steps defined within the feature file. 


Note: Line 20 uses GFeatureFile.execute to reference the G-Data Table and dynamically call the GenRocket runtime engine to launch and run the UserSceanario with the G-Case, BankTestCase.Load.load1000, which will insert 1000 users into the genrocket_bank.user table. The GFeatureFile class is located within the com.genRocket.engine jar.


package steps

import com.genRocket.engine.GRFeatureFile
import cucumber.api.DataTable
import util.QueryUtil

import static cucumber.api.groovy.EN.*

Integer userCount = 0, lastUserId = 0
final String USER_COUNT_QUERY = "select count(*) as count from user"
final String USER_LAST_ID_QUERY = "select id from user order by id desc limit 1"
final String USER_DELETE_QUERY = "delete from user where id > "

Given(~'^the count$') { ->
  userCount = QueryUtil.count(USER_COUNT_QUERY)
  lastUserId = QueryUtil.lastUserId(USER_LAST_ID_QUERY)
}

When(~'^users are loaded$') { DataTable arg1 ->
  GRFeatureFile.execute(arg1.asMaps(), false)
}

Then(~'^user count is increased by one thousand$') { ->
  assert userCount + 1000 == QueryUtil.count(USER_COUNT_QUERY)
}

Then(~'^users are deleted$') { ->
  QueryUtil.delete(USER_DELETE_QUERY + lastUserId)
  assert QueryUtil.count(USER_COUNT_QUERY) == userCount
}

Appendix

QueryUtil Class

The QueryUtil class contains helper methods that connect to a database and perform SQL operations. The QueryUtil thus allows step definition code to be clean, testable, free of database connection, execution concerns. The QueryUtil also enables step definitions to be unconcerned about the type of database it affects.


package util

import groovy.sql.Sql

class QueryUtil {

  static final String URL = "jdbc:mysql://localhost:3306/genrocket_bank"
  static final String USER = "root"
  static final String PASSWORD = "admin"
  static final String DRIVER = "com.mysql.jdbc.Driver"

  static Integer count(String query) {
    List list = execute(query)
    return list.first().count
  }

  static Integer lastUserId(String query) {
    List list = execute(query)
    return list.first().id
  }

  static void delete(String query) {
    def sql = Sql.newInstance(URL, USER, PASSWORD, DRIVER)
    sql.execute(query)
    sql.close()
  }

  static def execute(String query) {
    def sql = Sql.newInstance(URL, USER, PASSWORD, DRIVER)
    List results = sql.rows(query)
    sql.close()

    return results
  }
}