Evolving Tables Safely⚓︎

Feature tables change. A team renames a label. A new optional field appears. A parser becomes stricter. Old scenarios still matter, but new scenarios should read better.

Table evolution is healthiest when compatibility is intentional.

Renaming language⚓︎

An old table might use Full name:

Given the users exist
  | Full name | age |
  | Mira Rao  | 34  |

A newer table might prefer name and add active:

Given the users exist
  | name     | age | active |
  | Mira Rao | 34  | true   |

Both can be supported while the team migrates:

from talika import RowTable, boolean, field


class UserTable(RowTable):
    name = field("name", aliases=("Full name",), required=True)
    age: int = field("age", required=True)
    active = field("active", parser=boolean(), default=True)

The important part is that the old wording is visible. It is accepted because the project chose to accept it, not because the parser ignored differences.

See field aliases for the concrete migration mechanism.

Adding fields⚓︎

Adding a required field breaks old tables immediately. Sometimes that is the right choice. Other times the field should start as optional with a default, so old scenarios remain valid while new scenarios can be more explicit.

Preserving old information⚓︎

Some projects temporarily preserve old columns or variant-specific values while they migrate:

class LegacyUserTable(UserTable):
    inapplicable_fields = "preserve"

That should be a short-lived compatibility strategy, not the permanent design.

CI makes evolution safer⚓︎

When table rules are explicit, a checker can validate feature files before the scenario runs. That gives teams earlier feedback when a label changed, a parser became stricter, or a compatibility alias was removed.

The static-checking guide shows how to check feature tables from the CLI.