Replies: 2 comments 8 replies
-
|
Ok, you read a blogpost which is 8 years old. If you follow the modern trends and technologies you may notice that LOT of things has changed since that time. So I don't want to discuss something that was written 8 years ago. I don't have a time machine. Maybe you do. If you like Behat - use it That's simple. |
Beta Was this translation helpful? Give feedback.
-
It was the top result in google for a comparison between behat and codeception. Besides, the problem is not with it being outdated, but by the content. It is opinion-based and not backed by any facts, hosted(=endorsed by) on codeception.com. I know you guys are devs, but there's this not so new thing called public relations and marketing.
You don't have to. You can change the content, label it properly or take it down. Or even do nothing. It's all up to you.
Yeah. Great way of getting new users. Anyhow, for the record, I ended up going with |
Beta Was this translation helpful? Give feedback.
-
Good to know. Keep us updated! P.S> When I google technical information I always set 1 year filter. That really helps |
Beta Was this translation helpful? Give feedback.
-
In about 4 hours I've installed panther+driver (this took about 10 mins, mostly spent reading the panther doc), set up the first feature test (installing a plugin in wordpress), did some finishing touches (taking screenshot on error, assertions etc - panther by itself is not specific for testing) and set up a github workflow (I'm completely new to github workflows, that took most of the time). Don't know about codeception, but I guess that after 4 hours I'd still be fighting with the behat config. 😆 |
Beta Was this translation helpful? Give feedback.
-
|
@DavertMik some warning sign that it is an opinion blog post and that it is horribly outdated would be nice though. Even the answer to second question (Why can’t I write Codeception tests in human language like Behat does) has changed. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, Codeception got BDD support since that time 😄 So if the person who writes gherkin scenarios is not the person who automates them If the person who writes scenarios and implements test automation is the same person - they have pretty much the same problem (constant steps refactoring), but also this doesn't give any value on top. It makes sense to have BDD scenarios as public documentation. But still with the cost of extra coding, refactoring, etc. People tend to misuse BDD, that's still a valid thing. People don't take tradeoffs of BDD into account implementing it. |
Beta Was this translation helpful? Give feedback.
-
Such as? I said it before, this whole crusade against BDD without any factual background gives the impression that it's just a subjective rant without much knowledge on how it really works. When writing gherkin steps, a competent IDE would suggest / autocomplete existing steps. Yes, there are tradeoffs and annoyances, but unfortunately, I haven't seen them mentioned or compared against traditional test systems / codeception in that blog entry.. all I'm saying is that if the point of it was to convince me to switch to codeception, then it failed badly. If that wasn't the point, then you tell me. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, you say that I don't give arguments but...
How is this even related to BDD?
This also has no relation to BDD. You can develop small and meaningful tests without using BDD principles such us:
Just
Since 2012 we have a much better guide on BDD and its limits and how BDD can be combined with classical tests to resolve those issues https://codeception.com/docs/07-BDD#Tests-vs-Features I don't know why did you put all good code practices as a consequence of BDD. No, they are not even related. BDD is more about management and inter-team communication in a project. Did you hear "3-Amigo" term? Automated tests are a minor part of BDD. And following BDD principles can make harden the development of those tests. That's my point. This is why the post may sound counterintuitive to you. And this is why BDD can be harmful. People tend to think that BDD will solve all their issues - with tests, with clean code, with team communication. No. BDD is a set of principles that can either improve or harm test development, with its pros and cons. Anyway, unless you are following 3-Amigo principle - you are not doing real BDD. Problem is not in BDD itself. But with how people think of it. |
Beta Was this translation helpful? Give feedback.
-
|
You've got a point that BDD, from a general perspective, isn't related to code at all, but more of a high-level development principle.
When writing the user stories, you're forced to keep out implementation details. Again, within the context of Behat.
If we agree that behaviour is basically business logic, then as BDD goes, it means the behaviour/business-logic is written first - and then connected to the test system - therefore: clear separation between business and test logic.
I could ask that question as well. The article claims that using Behat/BDD is bad for DRY/KISS etc (when in fact it encourages and forces code reuse). Why? Behat (or mink, actually), by default, starts with a restrictive set of steps that should immediately give the idea that using selectors for everything in your tests is a bad idea. Codeception (within that article) and similar systems (like panther) start with a different ("more flexible") approach, without saying that it is a bad practice (quite the contrary, the article claims that using selectors everywhere is a good thing).
Agreed, from an organisational point of view, anything could screw up. However, the morality of that point is: it's not about the tool, but the usage. So you should now see why I wasn't expecting that point on a post comparing two tools. |
Beta Was this translation helpful? Give feedback.
-
Yes. In 2012 there was a huge public attack from Behat team on Codeception. And this post was my attempt to respond to it. Sure, the goal of this post was what it said - propose alternative to Behat and show weak points of Behat's approach.
Behavior is not really a business logic. Business logic is a decision unit inside an application while application behavior it what user sees. So when user clicks on site it takes down through all sub-systems to make that behavior works. But a business logic is only responsible to data changes within this action. For instance, I can write my behavior test on any of these levels:
The test layer that has the least dependencies on other sub-modules is testing business logic. Let's take REST API cases - should we write them in BDD manner as Gherkin scenarios? No, REST API is a technical interface, so usage of human-like language is not really needed. Should we test REST API before providing it to our React/Vue app? Sure! Where is BDD here? I don't know.
The idea of coupling Behat with Mink was also later taken as anti-pattern by Behat team (sorry, can't find their tweet from 2012). UI steps bound to user scenarios does not tell anything of application behavior, Gherkin scenarios transform into interface guides. If we change the button's position on the page the business scenario is not relevant anymore? BDD tests in Behat should be kept around business logic even when defining how to work with an application's interface. The approach of Codeception is quite different. We say that our tests are indeed user interface tests. And use any selectors you need to pass the scenario. We are focusing on tests. Cover your application with the required set of tests you need. This is absolutely ok. In BDD scenarios you use human-like language to define business scenarios What is antipattern in Behat+Mink is a pattern in Codeception. Just because of the different purposes of these tools.
Sorry, for my rude start. I understand this. But this post has its own context. And unfortunately, I can't reveal all the context it was created under. Codeception was attacked by Behat author who was more popular in PHP community than me. So maybe that what triggered me first. Yes, in that year this post was about Codeception vs Behat. Nowadays, things have changed and Codeception got its place under the sun. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Disclaimer: I've used Behat for a couple of projects extensively, so I know its upsides and downsides.
For a new project, I decided to reevaluate codeception as a solution and, long story short, I ended up on this page:
https://codeception.com/12-20-2012/not-bdd.html
In short, I decided to NOT use Codeception after reading that article due to how it is written. Here's a few points why:
$I->click('Order');instead of$page->dispatch(new MouseEvent(MouseEvent::LEFT_BUTTON));😉In the end, I was hoping to find some information on why I should use Codeception, instead of Behat (possible trimmed down) or even plain PHPUnit with Mink(for example) and instead I got a poorly-worded, misdirected bash of a competitor. 🤷♂️
Beta Was this translation helpful? Give feedback.
All reactions