u/chinmay_3107 — reddlx

▲ 22 r/Playwright+4 crossposts

I got tired of guessing step definitions, so I built a better BDD extension for VS Code (GherkinLens v2)

Hey everyone,

If you write .feature files in VS Code using pytest-bdd or behave, you probably know the pain of typing out steps from memory, hoping they match, or constantly grep-ing your codebase to find out how a step was implemented.

I actually developed this because our team was migrating from PyCharm, and I realized there was no full-scale solution for the Python Gherkin environment in VS Code. So, I built GherkinLens to solve all the editor and navigation problems first, and then started adding time-saving features.

I just released v2, which totally pushes it one step further, and I wanted to share it with you all.

Basically, it indexes your Python step definitions in the background (without actually importing or running your code) so you get a proper IDE experience for Gherkin.

Vscode extension - GherkinLens

Here's what I added in v2:

📚 Step Library: There's a new sidebar panel that lets you browse and search every step definition in your project. It even shows usage counts, so you know which steps are actually being used.
🏷️ Tag Explorer: You can finally see all your tags in one place, find scenarios easily, and run/debug them straight from the tree.
📊 Table Editor: I added a built-in spreadsheet editor for Examples tables. You can add rows, paste from Excel, or import CSVs directly into the feature file without messing up the pipe | alignment.
📋 Snippets: You can now save multi-step flows and drop them in anywhere.

It still has all the core features from v1 (the stuff that fixes the navigation problems):

⚡ Autocomplete & Go to Definition (F12) between your Gherkin and Python files.
⚠️ Squiggly lines for steps that don't match anything.
💡 Quick Fix (Ctrl+.) to auto-generate the Python stub for a missing step.
🏃 Native BDD Runner hooked into VS Code's Testing view.

It auto-detects whether you're using pytest-bdd or behave, so there's zero config needed.

If you want to try it out, just search for "GherkinLens" in the VS Code Marketplace. It's completely free.

Would genuinely love to hear what you guys think, or if there's anything driving you crazy in your BDD workflow that this could fix!

u/chinmay_3107 — 8 days ago

▲ 1 r/Everything_QA

Would typed schemas for pytest-bdd / Gherkin tables be useful?

The idea is to make BDD data tables feel a bit like dataclasses/Pydantic models.

Instead of manually parsing this in a step:

Given the following users exist:
  | name  | role  | active |
  | Alice | admin | true   |
  | Bob   | user  | false  |

You could write:

class UserTable(RowTable):
    name = field("name", required=True)
    role = field("role", required=True)
    active: bool = field("active")

Then:

users = UserTable.parse(datatable)

It would handle required fields, type conversion, custom parsers, validation, and better row/column errors. Business logic would still stay in your own step definitions.

For people using pytest-bdd / Gherkin:

Do your tables ever get annoying to parse manually?
Would a schema layer for tables help, or feel like too much abstraction?
Would you want this as a standalone Python package with pytest support?

The more advanced idea is that teams can add their own small table conventions without putting all that parsing logic inside every step definition.

Trying to sanity-check whether this solves a real problem before polishing it further.

reddit.com

u/chinmay_3107 — 19 days ago

▲ 0 r/Python

Would typed schemas for pytest-bdd / Gherkin tables be useful?

The idea is to make BDD data tables feel a bit like dataclasses/Pydantic models.

Instead of manually parsing this in a step:

Given the following users exist:
  | name  | role  | active |
  | Alice | admin | true   |
  | Bob   | user  | false  |

You could write:

class UserTable(RowTable):
    name = field("name", required=True)
    role = field("role", required=True)
    active: bool = field("active")

Then:

users = UserTable.parse(datatable)

It would handle required fields, type conversion, custom parsers, validation, and better row/column errors. Business logic would still stay in your own step definitions.

For people using pytest-bdd / Gherkin:

Do your tables ever get annoying to parse manually?
Would a schema layer for tables help, or feel like too much abstraction?
Would you want this as a standalone Python package with pytest support?

The more advanced idea is that teams can add their own small table conventions without putting all that parsing logic inside every step definition.

Trying to sanity-check whether this solves a real problem before polishing it further.

reddit.com

u/chinmay_3107 — 19 days ago

▲ 1 r/softwaretesting

Would typed schemas for pytest-bdd / Gherkin tables be useful?

The idea is to make BDD data tables feel a bit like dataclasses/Pydantic models.

Instead of manually parsing this in a step:

Given the following users exist:
  | name  | role  | active |
  | Alice | admin | true   |
  | Bob   | user  | false  |

You could write:

class UserTable(RowTable):
    name = field("name", required=True)
    role = field("role", required=True)
    active: bool = field("active")

Then:

users = UserTable.parse(datatable)

It would handle required fields, type conversion, custom parsers, validation, and better row/column errors. Business logic would still stay in your own step definitions.

For people using pytest-bdd / Gherkin:

Do your tables ever get annoying to parse manually?
Would a schema layer for tables help, or feel like too much abstraction?
Would you want this as a standalone Python package with pytest support?

The more advanced idea is that teams can add their own small table conventions without putting all that parsing logic inside every step definition.

Trying to sanity-check whether this solves a real problem before polishing it further.

reddit.com

u/chinmay_3107 — 19 days ago

▲ 0 r/QualityAssurance

Would typed schemas for pytest-bdd / Gherkin tables be useful?

I’m building a small Python package idea called bdd-tablex.

The idea is to make BDD data tables feel a bit like dataclasses/Pydantic models.

Instead of manually parsing this in a step:

Given the following users exist:
  | name  | role  | active |
  | Alice | admin | true   |
  | Bob   | user  | false  |

You could write:

class UserTable(RowTable):
    name = field("name", required=True)
    role = field("role", required=True)
    active: bool = field("active")

Then:

users = UserTable.parse(datatable)

It would handle required fields, type conversion, custom parsers, validation, and better row/column errors. Business logic would still stay in your own step definitions.

For people using pytest-bdd / Gherkin:

Do your tables ever get annoying to parse manually?
Would a schema layer for tables help, or feel like too much abstraction?
Would you want this as a standalone Python package with pytest support?

The more advanced idea is that teams can add their own small table conventions without putting all that parsing logic inside every step definition.

Trying to sanity-check whether this solves a real problem before polishing it further.

reddit.com

u/chinmay_3107 — 19 days ago

▲ 2 r/Python

I’m thinking about building a pytest / pytest-bdd plugin that helps teams define their own custom DSLs for BDD tables.

The idea is not to force one specific syntax. Instead, the package would provide the plumbing:

parse BDD datatables
let users define their own table shape
let users define their own range/repeat syntax
let users define custom cell parsers
validate rows/columns with better errors
convert tables into normalized Python objects
plug into pytest fixtures and pytest-bdd steps

For example, one team might use something like:

Given the following content exists:
  | Content IDs | 1..4      | 5    |
  | Content*    | 4:Article | Poll |
  | Category*   | random    | News |

But another team could define completely different syntax, like:

Given the following users exist:
  | Users | admin x2 | editor |
  | Role  | Admin    | Editor |

The plugin would not know what “Article”, “Poll”, “random”, or 1..4 means. The local project would define that.

I’m trying to understand:

Would you ever need something like this in real pytest-bdd projects?
Do your BDD tables ever become too complex or repetitive?
Is this useful, or would you rather keep this logic inside local step definitions?
Is there already a better way to solve this?
At what point does a table DSL stop being BDD and become too technical?

Curious to hear from people using pytest-bdd or BDD-style tests in real projects.

reddit.com

u/chinmay_3107 — 2 months ago

▲ 1 r/softwaretesting

I’m thinking about building a pytest / pytest-bdd plugin that helps teams define their own custom DSLs for BDD tables.

The idea is not to force one specific syntax. Instead, the package would provide the plumbing:

parse BDD datatables
let users define their own table shape
let users define their own range/repeat syntax
let users define custom cell parsers
validate rows/columns with better errors
convert tables into normalized Python objects
plug into pytest fixtures and pytest-bdd steps

For example, one team might use something like:

Given the following content exists:
  | Content IDs | 1..4      | 5    |
  | Content*    | 4:Article | Poll |
  | Category*   | random    | News |

But another team could define completely different syntax, like:

Given the following users exist:
  | Users | admin x2 | editor |
  | Role  | Admin    | Editor |

The plugin would not know what “Article”, “Poll”, “random”, or 1..4 means. The local project would define that.

I’m trying to understand:

Would you ever need something like this in real pytest-bdd projects?
Do your BDD tables ever become too complex or repetitive?
Is this useful, or would you rather keep this logic inside local step definitions?
Is there already a better way to solve this?
At what point does a table DSL stop being BDD and become too technical?

Curious to hear from people using pytest-bdd or BDD-style tests in real projects

reddit.com

u/chinmay_3107 — 2 months ago

▲ 1 r/QualityAssurance

I’m thinking about building a pytest / pytest-bdd plugin that helps teams define their own custom DSLs for BDD tables.

The idea is not to force one specific syntax. Instead, the package would provide the plumbing:

parse BDD datatables
let users define their own table shape
let users define their own range/repeat syntax
let users define custom cell parsers
validate rows/columns with better errors
convert tables into normalized Python objects
plug into pytest fixtures and pytest-bdd steps

For example, one team might use something like:

Given the following content exists:
  | Content IDs | 1..4      | 5    |
  | Content*    | 4:Article | Poll |
  | Category*   | random    | News |

But another team could define completely different syntax, like:

Given the following users exist:
  | Users | admin x2 | editor |
  | Role  | Admin    | Editor |

The plugin would not know what “Article”, “Poll”, “random”, or 1..4 means. The local project would define that.

I’m trying to understand:

Would you ever need something like this in real pytest-bdd projects?
Do your BDD tables ever become too complex or repetitive?
Is this useful, or would you rather keep this logic inside local step definitions?
Is there already a better way to solve this?
At what point does a table DSL stop being BDD and become too technical?

Curious to hear from people using pytest-bdd or BDD-style tests in real projects

reddit.com

u/chinmay_3107 — 2 months ago