The Table Boundary⚓︎

The most important idea in Talika is the boundary between authored table text and dependable Python data.

On one side of the boundary is the feature file:

Given the account holders exist
  | name | age | verified |
  | Mira | 34  | yes      |

On the other side is what the test setup really wants:

AccountHolder(name="Mira", age=34, verified=True)

The middle is where table work happens. The BDD framework can hand your step a datatable:

datatable = [
    ["name", "age", "verified"],
    ["Mira", "34", "yes"],
]

But it cannot know your project vocabulary. It does not know whether verified accepts yes/no, true/false, Y/N, or something more domain-specific.

Why the boundary should be explicit⚓︎

When table rules are implicit, they hide in step functions. That usually feels fine at first. Then a second step parses the same idea differently. Later, a feature author changes a label and the failure points to Python setup code instead of the table.

An explicit boundary gives the project one place to answer:

• what shape this table has
• which values are allowed
• how text becomes Python values
• how to report mistakes back to the feature author

from talika import RowTable, boolean, field


class AccountHolderTable(RowTable):
    name = field("name", required=True)
    age: int = field("age", required=True)
    verified = field(
        "verified",
        parser=boolean(true_values=("yes",), false_values=("no",)),
        default=False,
    )


holders = AccountHolderTable.parse(datatable)

The boundary is not business logic⚓︎

A table contract should not create accounts, call services, or perform the scenario action. It should prepare trustworthy input for that work.

The focused step-function pattern shows where parsing ends and scenario setup begins in a real test.