Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explanation on difference between BDD and Classical projects #164

Open
TetianaKhomenko opened this issue Oct 14, 2024 · 0 comments
Open
Assignees
Labels

Comments

@TetianaKhomenko
Copy link
Collaborator

Q: I have to ask what if I use gherkin tests in classical project? What would be the issue there?

A: Hi, the reason behind that i that Gherkin is much stricter format than markdown. So when you edit test in Gherkin you should follow syntax restrictions, also the main data is stored not in a test itself but in a feature file, a suite in our case. Having both markdown + gherkin in the same project may lead into mess: if you move a test from markdown to gherkin suite, you will get the Gherkin syntax broken. To not allow this kind of issues we recommend using different projects

Q: we are exploring options to automate our manual tests.
Manual test exists in a classical type project. However, we are contemplating using BDD for automation. I understand changing project type from "Classical" to "BDD" is not supported for projects that already have tests. Is there a way to move test from one project to another?
or is there an option for us to write bdd automation scripts for an existing manual test without having to re-create the test in another project?

A: Hi, unfortunately, there is no straightforward conversion classical => BDD as BDD is much stricter format than classical, so if you go that path you will need to rewrite all tests entirely. This is because each Step in BDD format must have a corresponding function in a code, so there should be a very limited set of Steps in your descriptions.
Also, BDD format is already descriptive so you don't actually need classical description + BDD description for a one test. That's the reason we don't support having both as it can lead to inconsistency on a long run.
I would recommend you to not go fully to BDD but choose a tool which brings best of two worlds: descriptiveness of BDD and flexibility of classical automation. If you haven't used BDD for automation before, I can warn you that you will face a lot of code-related issues with this approach.
So take a look at CodeceptJS for automation: https://codecept.io/
The test will look like this:

I.amOnPage('https://github.com/');
I.click('Sign in', '//html/body/div[1]/header');
I.see('Sign in to GitHub', 'h1');
I.fillField('Username or email address, '[email protected]');
I.fillField('Password', '123456');

Without all limitation BDD applies on test automation. And test is readable and easy to follow. Testomat.io has great support of CodeceptJS and it uses Playwright under hood.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants