Table Vocabulary⚓︎

As a test suite grows, feature tables often develop their own vocabulary. This is not a bad thing. It is how teams keep examples readable.

A content author might prefer this:

Given the articles exist
  | headline        | body                                | publish_date |
  | random          | 20 words                            | today        |
  | Release summary | The release shipped successfully.   | 2026-07-03   |

The words random, 20 words, and today are not Python values. They are project vocabulary. The project has to decide what they mean.

Compact table language⚓︎

Sometimes vocabulary belongs to the whole table shape, not just one cell.

Given the content exists
  | IDs  | 1-3        |
  | Type | 3 Articles |

This might mean:

[
    {"id": "1", "type": "Article"},
    {"id": "2", "type": "Article"},
    {"id": "3", "type": "Article"},
]

The compact form is easier to write. The expanded form is easier for test code to use. A good table layer lets the author write the compact form while keeping diagnostics tied to the original cells.

Own the language⚓︎

Talika gives hooks for project vocabulary, but the project owns the words.

@cells.token("random", fields=("headline",))
def random_headline(context):
    return context.user_data["faker"].headline()

That function is not merely a parser. It is a decision: in the headline field, the word random means "ask the test data generator for a headline."

For implementation choices, compare a custom compact-domain parser with CellDSL tokens for stable vocabulary.