From Records To Test Objects⚓︎

After a table is parsed, the test needs something useful to work with. That might be a Talika record, a dictionary for a factory, a dataclass, a Pydantic model, or a project object.

The first parsed result is usually a record:

users = UserTable.parse(datatable)

assert users[0].name == "Mira"
assert users[0].age == 34
assert users[0].as_dict() == {"name": "Mira", "age": 34}

Records are intentionally small. They hold declared fields as attributes and keep source information for diagnostics.

Records are good at the boundary⚓︎

Records are especially useful when the next step is a fixture or factory:

records = UserTable.parse(datatable)

created_users = [UserFactory(**record.as_dict()) for record in records]

The record owns table parsing concerns. The factory owns object creation. Those two jobs should stay separate.

Sometimes you want project objects directly⚓︎

A schema can configure a public output object after parsing and validation:

from dataclasses import dataclass

from talika import RowTable, field


@dataclass(frozen=True)
class User:
    name: str
    age: int


class UserTable(RowTable):
    output_model = User

    name = field("name", required=True)
    age: int = field("age", required=True)

Parsing still returns Talika records. Conversion is an explicit second API:

records = UserTable.parse(datatable)
users = UserTable.parse_as(datatable)

assert users[0] == User(name="Mira", age=34)
assert records[0].source_for("name").source_value == "Mira"

The practical distinction⚓︎

Use parse() for schema records: source metadata, as_dict(), and table-focused validation support. Use parse_as() when the caller is ready for a dataclass, Pydantic model, or another project object.

The output-model guide shows how to add a dataclass output model and how to choose the right return shape.