livt
livt /

livt and BDD

Where livt departs from the practice

Formulation: the Example Mapping is the source

In mainstream BDD, developers and testers write the rules and examples up as a feature file (Gherkin), and that file becomes the source of the specification. In livt, a YAML file in Example Mapping's own format is the source, and formulation is rewriting that file. A feature file, where a team wants one, would be generated from it, which livt does not do yet.

Product managers and designers can go on answering its questions and changing its rules in the Example Mapping they already know, so there is little new to learn.

The practiceExample Mappingwritten up by developers and testersfeature file (Gherkin)sourceDevelopers, testersThe feature file stays with development and testing.
livtExample Mappingrecorded, then rewrittenYAML in Example Mapping's formatsourceThe three amigosgenerated if wantedfeature fileProduct managers and designers join in answering questions and changing rules.

Automation: coding agents take it on

Coding agents can now take on automating what a team agreed. Following the test pyramid, one Example Mapping's rules and examples end up automated at different layers and in different languages. livt gives the agent a shape to follow and the tools to follow it, as a CLI and plugins. Tests cite rules and examples by their livt URI, and livt collects those citations into an automation report.

Example MappingR-01 · R-02 · EX-02
Backend (Go)// livt:automates livt://…/rule/R-01
Frontend (TypeScript)// livt:automates livt://…/rule/R-01/example/EX-02
End-to-end// livt:automates livt://…/rule/R-02
livt automationsCollects the tests' citations and writes the report
Automation reportWhich tests cite each rule and example

Learn it from the people who wrote it down

Most of what livt renders was worked out and published by the BDD community.