So I hacked together some funny code for default testing config in tests that uses some funny classes and dude even a really fancy (ugly) DI-alike service container that gives you access to default testing config provided by modules, and oh behave, it even works.

A full design, introduction, conversion, and integration of BDD/Behat will take a lot of time, and I definitely do not want to hold off the currently ongoing testing system improvements on that. But it surely can't hurt to explore ways that possibly lead to code that can be more easily migrated in the end.

So let's discuss, Mr. @weitzman, Mr. @beejeebus, Mr. @Sonnabaum! :)

This patch is reduced to the max, so non-functional. Comparing it with the patch above mentioned issue can't hurt to get a better understanding.

The hook would be ignorant to anything else and just go ahead and set up some config.

BDD/Behat tests use a rather high-level approach of integration testing. They set up dynamic, but not very granular configuration to test a certain scenario.

In turn, those tests will look along the lines of this:

Scenario: Edit a node Given a user "foo" And a node type "article" And a node When user "foo" can "edit article content" And I am logged in And I visit the node "Test" Then I should see a link: """ Edit """

(Please ignore exact details of this scenario. Figuring out the proper, modular macro language for those BDD/Behat tests is exactly the reason for why I think this will take a lot of time to get done.)

That direction will require something very similar to default configuration for tests.

But instead of default configuration being ignorant to any scenario and conditions, this asks for individual pieces of things you can set up for a specific scenario.

In turn, it might make sense to at least introduce the default config for tests in a way that would be basically "compatible" with that direction.

I.e., instead or in addition of blatantly setting up default config for all modules, allow modules to expose methods that allow a test to pull in particular pieces of predefined configuration.

Here are integration tests and step definitions that Acquia uses to test Drupal Commons. We have a similar suite for Drupal Gardens. We've been using BDD for a while now and we think it is a great fit for Drupal. Drupal's modularity and reuse leads to only a few, powerful step definitions.

Please open up the zip and take a look around. The step definitions are written in Ruby since we chose Cucumber a while ago. Drupal 8 would use Behat instead, and thus use PHP instead of Ruby.

This issue suggests smaller steps toward BDD in Drupal 8. Small steps are good. I attach this Zip to show what the end goal could look like.

To some degree, I think that module testing, as the current examples show it, are more likely to be realistic as integration tests (à la RSpec) than full-stack tests, for exactly the reasons you outline, Mocks and seams, might be adjustable by tweaking the hook system, and can help combine individual mechanisms (hence testing integration) while still limiting the impact of the rest of the configuration, making test scenarios realistic.

The problem of course, being that PHPspec is far less legible/handy than its original counterpart, unlike Behat vs Cucumber, where the features almost don't change, and the step definitions are atually not so bad to read than one could have expected. Maybe there are better alternatives ?