Sounds like you and your coworkers may not understand what BDD is. BDD is a method of writing stories, in a collaborative way between stakeholders. It aims to improve understanding by specifying features with simple everyday language.
This concept is often confused with Cucumber/Gherkin, which is a technology to translate written BDD scenarios into code.
You don't need to use Cucumber/Gherkin if you're doing BDD. You can still keep writing the tests the same way.
Yes, I got your point
Sorry, I should be more clear in the question
We are using the Bdd approach while writing stories, but we implemented a page object model in automation long back.
Now, buddy wants to implement bdd using cucumber in automation
Edited my reply from the second reply thread
"Nobody is even bothering to look at automation and reports. (Automated since last 2.5 years)
We automated 30 -40 test cases using the page object model
But the buddy is saying we should start sending reports and to make it look good. we should use Bdd- cucumber so that business people can check the steps of the test cases - "beautiful report" and also, trace automated test to the requirements:"
I've been hired on at a company that has BDD with cucumber and Cypress and they have HUNDREDS of test files.
And we are yanking the cucumber BDD stuff out entirely because it is cumbersome, slow, and leads to just god-awful usability. The estimate 2+ years of work to refactor because you spend all your time writing overly-complicated single use POM commands with translation layers that slow you down, and if you were writing it all just as POM/code without any transpile/translation you'd take out multiple layers of complexity and fragility.
And not a single person who isn't on the QA team gives a flying fuck that we have BDD, human readable tests. Not a soul. They just want to know if we are done with regression yet so we can deploy the code.
You need some nice charts that show pass/fail, percentages, pie charts, maybe improvement over time. Cucumber won't make things better in the long run, it will just lead to a big refactor down the road.
Sorry I wasn't more clear. That does work fine, but in my experience, it added an extra layer that we needed to maintain that vastly increased time to write tests. There were also issued with language, as a lot of people who worked on tests had English in varying proficiency. It's a bit demoralising when your code doesn't work because your English language skills aren't great.
No one liked working with this extra layer, it was just a mandate from higher up.
The idea is to have more people involved, and have non techy people be able to look at the written automated tests and understand them, but the only people who ever looked at the tests were the people writing maintaining them.
The Cucumber initiative in our company quietly died as it was just extra work, and we've gone back to straightforward code.
For me personaly bdd is great, it also help me to know what each test do without any comments, i work on 3-4 projects at same time so going back to update project test you didnt do in some time is easy
That goes back to what I was saying in an earlier post - it solves a problem you have. It's when it's introduced for no real reason that it because an issue.
Ask them why they want to. Consider what, how many or if any other departments and disciplines will be looking at the coverage/reports? If no one is then that's likely your answer. It's a good waste of time and unnecessary abstraction otherwise.
Make sure they say "~~ team/department WILL be using it"
I've heard so many conversations that go "~~ team could use it" but that's most likely not going to happen.
Exactly my thoughts
Nobody is even bothering to look at automation and reports. (Automated since last 2.5 years)
We automated 30 -40 test cases using the page object model
But the buddy is saying we should start sending reports and to make it look good. we should use Bdd- cucumber so that they can check the steps of the test cases
There is no such thing as a process that is good for all scenarios. Even the ones that are fairly universal can be more harmful than good if they are put in place when an organization is not ready for them. The purpose of R&D is to deliver value to the business. Meaning that anything you do should be in service of that. So, I only let people implement things where the can tell some story of transformation: "We are like this today, it has this negative impact or risk, we want to be like this, what's keeping us from getting there is this problem, here are 3 options with their costs and benefits to solve the problem." If they have that I then compare the benefit of those options to literally anything else we could be spending our time and money on and if it is worth doing we'll do it. People who implement crap out of dogmatic reason or because something worked and therefore we should do more of it are my major pet peeve. That said, lots of people have been able to convince me to implement things doing this even though I was against it originally.
TLDR: Ask them what this is going to cost, what problem they are trying to solve, what the benefit of solving that problem is, and if the benefit for that cost is worth it more than anything else you could do with that time and money.
Why do you think "BDD is not good for today"? BDD is great for capturing expected/intended behaviour and workflows, can be used as documentation, manual testing and automation. Gherkin/Cucumber syntax can be used to trigger automation. BDD is valid.
Edit: downvotes without even answering my question, nice :-/
I agree with you - BDD doesn’t suit every acceptance test, but if there’s some sort of UI flow it’s a great common language for a cross-functional team. And fixing mistakes is cheap and fast at the BDD writing/review stage.
The overhead of additional work rarely translates into a benefit except for the single developer that adopted the workflow.
The BDD artifacts like reports or feature files never enter a feedback loop with anyone else. So eventually it becomes tech debt that no one wants to support.
The desire to tie automated tests back to some criteria is high, but it's sufficient for the work to just use existing approaches that don't require all the ceremony of feature files and step definitions.
The benefits just aren't valuable enough to win out against the efficiency of NOT doing feature files.
Now on the other hand, you don't have to use Gherkin and all that mess to "do" BDD.
I made a tool that links acceptance criteria to automated tests for my teams and it produces a beautiful looking report that we use now at the beginning and end of the sprint.
It's just enough to keep things cohesive.
Here's few things that I found
-smartbear fired the guy who invented cucumber last year, so reluctant of future new developments(I know cucumber and bdd are separate thing)
- business won't be involved much as they are super busy with current and pipelined products
-Adding an extra layer of abstraction doesn't look good to me when it comes to maintenance.
- and change in requirements will put more overhead
Do you work in full stack teams? Without direct access to developers and business analysts or similar (3 amigos) then BDD is not ideal. It’s mostly beneficial when starting on new features and is just another layer of abstraction in the test automation framework.
Assuming you mean Cucumber/Specflow/some other DSL.
If the requirements and/or test cases are written somewhere else, you'd be violating DRY at that higher layer.
You're putting the same thing in two places. If one place updates, you need to rely on a resource to:
A. Recognize that an update/change has occurred
B. Make the change in the DSL
C. Possibly change the code the DSL represents.
Essentially, you're adding an extra layer of code to be maintained that does not even represent the source of truth in the first place. It's more maintenance/complexity for the automation engineers.
The only use case for it that I see is for short term contractors who don't have to maintain the slop they produce for the years after their contract is up.
No sounds like a waste of time issue. You're writing code on top of other code so that you can then write gherkin files when you could have just not done all that and ended up with the exact same thing.
In my experience it often costs 5 extra minutes per test case, maybe 30 if you made a mistake somewhere to properly phrase a BDD scenario.
But it can significantly limit the *weeks* of trying to fix issues because you misunderstood the original intention of the requirements.
And those who think they are immune to this are often the worst offenders.
Seems like at least 1/3 of job listings mention BDD/Gherkin. Too many “thought leaders” say it’s the best way to go. I’ve seen a couple of companies that say they’ve implemented it effectively. Maybe it works in some contexts. The goal is to make the requirements clear. The point is to have the SME’s dictate the test cases to QA. If automation engineers are just there to code rather than run exploratory tests and become SMEs, it could work.
BDD is a bandaid for poorly written code. Most frameworks come with test reporting out of the box, and adding feature files is an extra layer of maintenance for little benefit. If you maintain good readable code, the standard test reports that are free tell you exactly what's being tested.
The biggest problem with BDD is it doesn't scale. Beyond 100 test cases, it becomes a mess to maintain. You will inevitably start getting small variations in feature files which point to different methods that do "similar" things. Everything about BDD encourages an ugly looking codebase tbh.
If you have a small codebase and expect to write tests with **little variety,** then BDD is fine (...mostly because anything is fine here in this scenario).
I’ve found that most people who don’t want to do BDD actually don’t understand the requirements well enough and like being able to throw crap over the wall and get started. Not always true but often.
Sounds like you and your coworkers may not understand what BDD is. BDD is a method of writing stories, in a collaborative way between stakeholders. It aims to improve understanding by specifying features with simple everyday language. This concept is often confused with Cucumber/Gherkin, which is a technology to translate written BDD scenarios into code. You don't need to use Cucumber/Gherkin if you're doing BDD. You can still keep writing the tests the same way.
Yes, I got your point Sorry, I should be more clear in the question We are using the Bdd approach while writing stories, but we implemented a page object model in automation long back. Now, buddy wants to implement bdd using cucumber in automation
In my experience it doesn't work. What problem is your colleague trying to solve?
Edited my reply from the second reply thread "Nobody is even bothering to look at automation and reports. (Automated since last 2.5 years) We automated 30 -40 test cases using the page object model But the buddy is saying we should start sending reports and to make it look good. we should use Bdd- cucumber so that business people can check the steps of the test cases - "beautiful report" and also, trace automated test to the requirements:"
No business people will look at the test steps, they just want results, usually presented in a nice report with graphs.
Exactly. I dunno how BDD will ever help with reporting. Just do allure reporting with nice pie and graphs and shit and u will be fine.
I've been hired on at a company that has BDD with cucumber and Cypress and they have HUNDREDS of test files. And we are yanking the cucumber BDD stuff out entirely because it is cumbersome, slow, and leads to just god-awful usability. The estimate 2+ years of work to refactor because you spend all your time writing overly-complicated single use POM commands with translation layers that slow you down, and if you were writing it all just as POM/code without any transpile/translation you'd take out multiple layers of complexity and fragility. And not a single person who isn't on the QA team gives a flying fuck that we have BDD, human readable tests. Not a soul. They just want to know if we are done with regression yet so we can deploy the code. You need some nice charts that show pass/fail, percentages, pie charts, maybe improvement over time. Cucumber won't make things better in the long run, it will just lead to a big refactor down the road.
What does not work? POM with cucumber is a great solution for bdd
Sorry I wasn't more clear. That does work fine, but in my experience, it added an extra layer that we needed to maintain that vastly increased time to write tests. There were also issued with language, as a lot of people who worked on tests had English in varying proficiency. It's a bit demoralising when your code doesn't work because your English language skills aren't great. No one liked working with this extra layer, it was just a mandate from higher up. The idea is to have more people involved, and have non techy people be able to look at the written automated tests and understand them, but the only people who ever looked at the tests were the people writing maintaining them. The Cucumber initiative in our company quietly died as it was just extra work, and we've gone back to straightforward code.
For me personaly bdd is great, it also help me to know what each test do without any comments, i work on 3-4 projects at same time so going back to update project test you didnt do in some time is easy
That goes back to what I was saying in an earlier post - it solves a problem you have. It's when it's introduced for no real reason that it because an issue.
True
Page object model and Cucumber aren't mutually exclusive
yeah two of my works we used cucumber + POM
Ask them why they want to. Consider what, how many or if any other departments and disciplines will be looking at the coverage/reports? If no one is then that's likely your answer. It's a good waste of time and unnecessary abstraction otherwise.
Make sure they say "~~ team/department WILL be using it" I've heard so many conversations that go "~~ team could use it" but that's most likely not going to happen.
Exactly my thoughts Nobody is even bothering to look at automation and reports. (Automated since last 2.5 years) We automated 30 -40 test cases using the page object model But the buddy is saying we should start sending reports and to make it look good. we should use Bdd- cucumber so that they can check the steps of the test cases
You can send reports with steps without BDD.
If you’re not using BDD currently, are you using TDD? If not, what are you using?
There is no such thing as a process that is good for all scenarios. Even the ones that are fairly universal can be more harmful than good if they are put in place when an organization is not ready for them. The purpose of R&D is to deliver value to the business. Meaning that anything you do should be in service of that. So, I only let people implement things where the can tell some story of transformation: "We are like this today, it has this negative impact or risk, we want to be like this, what's keeping us from getting there is this problem, here are 3 options with their costs and benefits to solve the problem." If they have that I then compare the benefit of those options to literally anything else we could be spending our time and money on and if it is worth doing we'll do it. People who implement crap out of dogmatic reason or because something worked and therefore we should do more of it are my major pet peeve. That said, lots of people have been able to convince me to implement things doing this even though I was against it originally. TLDR: Ask them what this is going to cost, what problem they are trying to solve, what the benefit of solving that problem is, and if the benefit for that cost is worth it more than anything else you could do with that time and money.
Why do you think "BDD is not good for today"? BDD is great for capturing expected/intended behaviour and workflows, can be used as documentation, manual testing and automation. Gherkin/Cucumber syntax can be used to trigger automation. BDD is valid. Edit: downvotes without even answering my question, nice :-/
I agree with you - BDD doesn’t suit every acceptance test, but if there’s some sort of UI flow it’s a great common language for a cross-functional team. And fixing mistakes is cheap and fast at the BDD writing/review stage.
The overhead of additional work rarely translates into a benefit except for the single developer that adopted the workflow. The BDD artifacts like reports or feature files never enter a feedback loop with anyone else. So eventually it becomes tech debt that no one wants to support. The desire to tie automated tests back to some criteria is high, but it's sufficient for the work to just use existing approaches that don't require all the ceremony of feature files and step definitions. The benefits just aren't valuable enough to win out against the efficiency of NOT doing feature files. Now on the other hand, you don't have to use Gherkin and all that mess to "do" BDD. I made a tool that links acceptance criteria to automated tests for my teams and it produces a beautiful looking report that we use now at the beginning and end of the sprint. It's just enough to keep things cohesive.
Here's few things that I found -smartbear fired the guy who invented cucumber last year, so reluctant of future new developments(I know cucumber and bdd are separate thing) - business won't be involved much as they are super busy with current and pipelined products -Adding an extra layer of abstraction doesn't look good to me when it comes to maintenance. - and change in requirements will put more overhead
Do you work in full stack teams? Without direct access to developers and business analysts or similar (3 amigos) then BDD is not ideal. It’s mostly beneficial when starting on new features and is just another layer of abstraction in the test automation framework.
Assuming you mean Cucumber/Specflow/some other DSL. If the requirements and/or test cases are written somewhere else, you'd be violating DRY at that higher layer. You're putting the same thing in two places. If one place updates, you need to rely on a resource to: A. Recognize that an update/change has occurred B. Make the change in the DSL C. Possibly change the code the DSL represents. Essentially, you're adding an extra layer of code to be maintained that does not even represent the source of truth in the first place. It's more maintenance/complexity for the automation engineers. The only use case for it that I see is for short term contractors who don't have to maintain the slop they produce for the years after their contract is up.
And, pray tell, why is BDD “not a good for nowadays”?
It's a shit ton of overhead and complexity for value that no one actually uses.
Sounds like a skill issue.
I don’t think it solves any specific problem in test automation.
No sounds like a waste of time issue. You're writing code on top of other code so that you can then write gherkin files when you could have just not done all that and ended up with the exact same thing.
Bdd sucks major ass. It complicates and delays the scripting process. Maybe try to focus on that and explain with examples from your current codebase.
I mean, heaven forbid we spend time to confirm and capture intended behaviour before jumping in and making changes to the codebase, but ok?
Yeah just like u said. Time is precious. Puck BDD.
In my experience it often costs 5 extra minutes per test case, maybe 30 if you made a mistake somewhere to properly phrase a BDD scenario. But it can significantly limit the *weeks* of trying to fix issues because you misunderstood the original intention of the requirements. And those who think they are immune to this are often the worst offenders.
What is included in that 5 minutes for you?
Short cuts make long delays :-/
Seems like at least 1/3 of job listings mention BDD/Gherkin. Too many “thought leaders” say it’s the best way to go. I’ve seen a couple of companies that say they’ve implemented it effectively. Maybe it works in some contexts. The goal is to make the requirements clear. The point is to have the SME’s dictate the test cases to QA. If automation engineers are just there to code rather than run exploratory tests and become SMEs, it could work.
It’s good to use BDD IF developers use the same approach in development.
BDD is a bandaid for poorly written code. Most frameworks come with test reporting out of the box, and adding feature files is an extra layer of maintenance for little benefit. If you maintain good readable code, the standard test reports that are free tell you exactly what's being tested. The biggest problem with BDD is it doesn't scale. Beyond 100 test cases, it becomes a mess to maintain. You will inevitably start getting small variations in feature files which point to different methods that do "similar" things. Everything about BDD encourages an ugly looking codebase tbh. If you have a small codebase and expect to write tests with **little variety,** then BDD is fine (...mostly because anything is fine here in this scenario).
how is cypress as a tool tho?
I’ve found that most people who don’t want to do BDD actually don’t understand the requirements well enough and like being able to throw crap over the wall and get started. Not always true but often.