Discuss Audience, Purpose, Plan, Concerns about using Behat for testing Drupal core on Drupal.org

Count me in. I'm using behat for a long time and also think that behat should be part of drupal core along side the simple/unit tests.
Although it a little bit early to talk about behat inside the core but there is some work for that so i think this is balanced.

Me too. We should get some input from the drupal.org QA team, who have been using behat for some time and have documented their approach (https://drupal.org/node/1551234).

Another problem that we need to handle is the UI. For now i don't think that there is a UI to run tests.

I'm all for this, but we should be clear what we're using Behat for. Behat is good for doing web automation testing in so far as it 'democratises' the creation of these tests as it abstracts the need to interact directly with Mink and it's drivers. However use of Behat doesn't mean that you're doing BDD, just as BDD doesn't 'require' automated tests.

BDD on the other hand is concerned with the process of requirements discovery and analysis, and describing product features in the language of the business domain which should result in product owners essentially writing unambiguous and comprehensive acceptance criteria and documentation which just happen to happily double as automated tests which clearly specify the intent of the product.

So as far as I see it we can view Drupal (core) as a product and attempt to do BDD and write tests such as the following:
"If I login as an administrator
And I view the list of site users
And I select a user who is not me
Then I should be able to delete them"
, and encourage module maintainers to do the same so that the intent of the module is clear wrt its behaviours.

Or we could use Behat as an easier way of writing functional tests to drive a browser, replacing DrupalWebTestCase, and help module maintainers clearly define what properly belongs in a unit test, and what in a functional test.

Whichever approach we use for core though, it's great progress!

I think that we don't need to think what is BDD or how behat will merge to that or driven from - we need to think what it will give us. I can say that will give, as @alarcombe said, a easy way to test the Drupal core and the contribution module.

When i'm writing "simple" tests for modules, for our projects we using behat, i get lost in the test and i need to write comments and documentation to the code instead of actually test it.
Also, when someone create a patch, the patch don't come along with "simple" test and i need to write for this a test. If we use behat as part of drupal core the patch could include behat tests because it's a lot more easy to write a behat test which mean that this improve the QA of Drupal core an the contributed modules.

More things i would like to point:
1. I think that development should take place first at GitHub: the workflow there is much more easy. You have PR, comments on the code in the PR. People can fork the project and not all the time upload the patch which is a really frustrating workflow.
2. Why the repository contain the D8 files? They should be decoupled, like every contribute module development process.
3. This one is out of topic: i tried to run the test but i got the PHP Magic Quotes issue. I'm running a mac osx, search all the web for a solution but nothing.

In response to #4

My view on viewing drupal like a product and having the BDD tests like requirements that are driving the development of the project (a la proper BDD), is that would be a potential minefield (both community and code related), and I don't think it would work (in the current climate).

I see the real benefit of behat as using it as a tool to drive functional testing. this would give a few advantages -
- tests are in plain english, opening up functional testing to more than just developers (who currently need to code simpletests).
- tests are quicker to write (because of the above, them being in plain language)
- tests are easier to maintain (you dont have to change the test when the version of drupal changes, only when the functionality does) - With simpletest when the drupal API changes, we also need to change the tests (because they are code). Yes we will have stuff that integrates with the drupal API but it will be in one place (the drupal behat extension), rather than scattered throughout every modules code.
- the behat framework is used by other projects (e.g. symfony)
- with things such as saucelabs we open up testing to different operating system / browser configurations (with little development) - which is currently impossible with simple test + the current testbot
- combining phpunit with the addition of behat (to replace simple test web tests) goes one step further to removing a dependency on simpletest for core

in response to #5
1. I think we can discuss how we do development when we decide how we are going to do stuff (e.g. address all the concerns in yesCT initial post)
2. The repo contains d8 files, because it is a core sandbox repository (e.g. Same as twig sandbox - https://drupal.org/sandbox/pixelmord/1750250). This shows how it can be integrated into Drupal core. The initial idea down the line would be to have behat integrated with drupal core (not contrib), so we can use behat tests for core modules / functionality. contrib can then obviously harness that functionality too.
3. Sounds like an issue with your php configuration. Please post another issue (outside this one) if you want help as not to distract from the point of this discussion

Added #1567500: [meta] Pave the way to replace the testing framework with PHPUnit and possibly rewrite Simpletest to the list of related issues

Just discovered the Moodle has integrated Behat (http://docs.moodle.org/dev/Behat_integration) so might be worth a look at their approach.

Moodle integration

It follows the approach chosen with PHPUnit:

It comes disabled by default, Behat is not included within Moodle and it has to be installed separately with the composer installer
Moodle components (subsystems and plugins) can have a tests/behat/ folder
The scenarios are executed in a test environment, the production database and dataroot are not affected by the tests modifications
The scenarios specifies their own fixtures and it's execution is isolated from other scenarios and features, resetting the test database and the test dataroot before each scenario
Moodle lists the features files and steps definitions of it's components in a behat.yml file, similar to the phpunit.xml manifest
A basic behat.yml.dist config file has been included

Added https://drupal.org/node/1567500#comment-7631211

Great discussion and input here. At this point, the momentum in the community has swung to using Behat/Gherkin for front end feature testing. We have an action-driven meta issue here: #2232271: [Meta] Use Behat for validation testing.

I would like to close this issue as a duplicate. I've linked to it from the meta above.