View on GitHub BDD For All

Flexible and easy to use library to enable your behavorial driven development (BDD) teams to easily collaborate while promoting automation, transparency and reporting.

Generating Data (and Variables)

To make life simpler - for us and you - we’ve exposed a faker macro to make it easy to generate all kinds of data.

Based on the JAVA Faker library (which itself is based on the Ruby Faker library, this powerful macro let’s you generate all kinds of data, in a bunch of languages!

First an example

Let’s say you want to create a record. That record requires some user information, maybe an address, and phone and some other data. You could hardcode this into your scenario, or, even better, you could use the faker macro…

  Scenario: Create a sales lead record.
    Given I am a JSON API consumer
      And I am executing test "SALES_LEAD_CREATE"
     When I request GET "/mirror"
      And I set the JSON body to
      """
      {
        "lead": {
          "leadId": "",
          "first_name": "",
          "last_name": "",
          "suffix": "",
          "phone": "",
          "address": {
            "line1": "",
            "city": "",
            "state": ""
          }
        }
      }
      """
     Then I should get a status code of 200
      And the response value of "lead.leadId" should equal ""
      And the response value of "lead.address.city" should equal ""

What We Did

Using our standard macro syntax this really breaks down to…

    • faker is the name of the macro to be executed
    • isNumber.valid are actually method calls on the faker object, in this case faker.idNumber().valid()
    • en-US is the locale to be used to generate. The faker lib supports like 40 locales
    • ::leadId is optional. :: is used as a separator, this tells the macro to store this value in the simple cache. leadId is the key for the cached value.

As noted in #4 above the ::leadId argument of the macro is optional, but it provides you a way to reference dynamically generated data for validations. Much the same way we use Response Chaining, this is a powerful feature. Take for example, the lines…

      And the response value of "lead.leadId" should equal ""
      And the response value of "lead.address.city" should equal ""

In this case, when generating the data to send, we also told the program to cache. The particular service we’re using sends some elements back to us, which we can then validate to make sure the record was saved correctly.

Want to run the same test case in multiple languages? You can! See Scenarios for more information.

Simple Variables

You can also use variables straight out of your config in your tests. Let’s use the example below…

bdd-for-all:
  vars:
    User:
      Name:
        First: Mike

By adding in a “vars” section to the config, you can inject all sorts of things into your tests. For example, with the above configuration, we could write a simple test like…

  @Smoke @Json @Vars @ResponseMatch
  Scenario: Testing out (VT1)
    Given I am a JSON API consumer
      And I am executing test "VT1"
     When I request GET "/mirror"
      And I set the JSON body to
      """
      {
        "lead": {
          "first_name": ""
        }
      }
      """
     Then I should get a status code of 200
      And the response value of "lead.first_name" should equal "Mike"

The runner will transform this to…

  ...
      """
      {
        "lead": {
          "first_name": "Mike"
        }
      }
      """
  ...