liveBook · Manning

Database table

As explained in BDD in Action, Second Edition

A table is a structured arrangement of related values in rows and columns that can represent complex scenario data.

A rule such as “credit recent flights” sounds clear until the team asks what counts as recent and which flights qualify. A table puts candidate flights in rows and the facts that affect eligibility in columns. Eligible and ineligible rows make exceptions visible: a flight may be too old, belong to another airline, be cancelled, or not yet have taken place. A note can preserve a boundary rule, such as when the 90-day period starts. section 6.3

Flight Number

Flight Date

Status

Eligible

Reason

FH-99

60 days ago

COMPLETED

Yes

 

FH-87

100 days ago

COMPLETED

No

Too old

OH-101

60 days ago

COMPLETED

No

Not a Flying High flight

FH-99

60 days ago

CANCELLED

No

Must be completed

FH-99

In 5 days time

CONFIRMED

No

Must have taken place

Compare the rows to see how date, flight number, and status each change the eligibility decision. section 6.3

In an executable scenario, a data table keeps related values beside the step that needs them instead of repeating account details across many sentences. Rows can represent several records; two columns can describe the fields of one record; a single column can hold a list. Column headers help readers interpret the values. Tables following Given or Then steps can state starting conditions or expected results, while tables of examples can supply variations of a scenario. section 7.3 section 7.3.1

Scenario: Transfer points between family members
    Given Danielle and Martin are family members
    And they have the following accounts:
      | owner     | points | status points |            #1
      | Danielle  | 100000 | 800           |            #1
      | Martin    | 50000  | 50            |            #1
    When Martin transfers 40000 points to Danielle
      | owner    | points | status points  |            #2
      | Danielle | 140000 | 800            |            #2
      | Martin   | 10000  | 50             |            #2

The account rows show how one compact structure replaces repeated point balances in a transfer scenario. section 7.3.1

For automation, each row can become a domain object passed to a step definition. Cucumber can expose the raw DataTable for manual extraction, but a DataTableType conversion moves that mapping out of the step definition. Keep the table focused on business-relevant fields so the scenario remains useful as living documentation. section 8.4.5 section 7.3

Scenario: Completed flights in the past 90 days can be claimed
  Given Todd joined the Frequent Flyer program on 2020-01-01
  When Todd asks for the following flight to be credited to his account:
    | Flight Number | Date       | Status    |
    | FH-101        | 2019-12-01 | COMPLETED |
    | FH-102        | 2019-12-01 | CANCELED |
    | FH-103        | 2019-08-01 | COMPLETED |
  Then only the following flights should be credited:
    | Flight Number | Date       | Status    |
    | FH-101        | 2019-12-01 | COMPLETED |

The requested-flight and credited-flight tables distinguish input records from the expected outcome. section 8.4.5

How BDD in Action, Second Edition covers it

How deep it goes
Shows several table shapes and follows flight rows through Cucumber DataTable extraction and domain-object conversion.
Examples
Contrasts eligible flights by age and status, account balances before a points transfer, and requested flights against credited flights.
What it assumes
Builds on Given–When–Then scenarios while explaining pipe-separated tables and showing the Java step definitions used for automation.
What you can do after
Apply it via Cucumber to express readable scenario data and convert flight rows into domain objects for automated steps.
How it connects
Connects tables to business rules, Given–When–Then scenarios, living documentation, step definitions, and domain objects.

Also explained in

Compare how 12 books explain database table →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of BDD in Action, Second Edition. The section links point to the parts of the book it draws on.