The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

Are you confused by Behat / Gherkin?

Submitted by nk on Wed, 2013-02-13 20:24

I presume you read some Behat/Gherkin tutorials which go: "With BDD, you write human-readable stories that describe the behavior of your application." Well, WTF, how does that human readable story become code? The answer is, which I have never seen clearly written: you write it, without any help, whatsoever. Behat does not provide any assertions, any helpers, it's an extremely thin test runner. You need to write a test class, mandatory name "FeatureContext.php". Behat provides you with some annotations (@Given, @When, @Then, @But, @And) and each method in FeatureContext.php has one of annotations plus a preg which will match one (or more) line from that human readable story. The annotations specify no behaviors, to Behat they are actually totally equal, they are just used to match the lines from the Gherkin file. Finally, the only way to fail is to throw an exception. Pass is very Unix-y: if no exceptions are thrown, it's a pass. Here's an example:

<?php
/**
* @Given /^I am in a directory "([^"]*)"$/
*/
public function iAmInADirectory($dir)
{
    if (!file_exists($dir)) {
        mkdir($dir);
    }
    if (!is_dir($dir)) {
      throw new Exception('Directory not found');
    }
    chdir($dir);
}
?>

Commenting on this Story is closed.

Such is the design of BDD.
Submitted by Anonymous on Wed, 2013-02-13 23:56.

Your tests should be concise and readable by everyone which is involved in the project - including stakeholders, which means being free of implementation details. They are specifically about enforcing business value of the system under test, and shouldn't need to be modified if a directory path changes.

Step definitions can only go so far to provide step definitions that provide reusable behavior, yet avoid leaking details into your scenarios which don't belong there. Your step here is a perfect example.

An ideal scenario might look something like:

  Feature: Comments
    In order to facilitate discourse related to our blog posts, users should be able to post comments.

  Scenario: Anonymous comments
    Given I am not logged in
    When I view a blog post
    Then I should be able to post a comment

Only after you've agreed upon what the intended behaviors are via this process of defining who, what where and why does it begin to matter how. You can take a feature like this and implement the steps using Cucumber, Behat, or Lettuce, and implement the system under test in whatever is appropriate given the behaviors defined during discovery. During this phase, the text of the tests should not be modified, unless the desired behavior also changes and in such a case, requires a new conversation and sign-off by the interested parties. That conversation and sign-off is most of the point. Most of the value of BDD comes before the test passes for the first time, test coverage of previously implemented behaviors should almost be considered a side-effect of the process.

It's pretty easy to misunderstand the point of BDD (I certainly did when I first discovered the concept), it's not just about testing. BDD is about fostering a communication process which results in a specification which is a living document which enforces the behavior of the system under test - if one changes so must the other.

If you just want test coverage of a system, you'll have an easier time not fussing with all of the regexps.

Here's a good video if you've got the time: http://vimeo.com/43612884

However, there are extensions that provide many of the steps you're asking for here and don't mind disregarding the above:

https://github.com/Behat/MinkExtension - Steps to automate web browsers
http://drupal.org/project/drupalextension - Steps to manipulate Drupal

You completely missed the point
Submitted by Anonymous on Thu, 2013-02-14 03:43.

Thanks for providing one of those articles that my post provides the "missing manual" for.

Go ahead and glue spaghetti together with regular expressions
Submitted by Anonymous on Tue, 2013-02-19 03:41.

I figured I'd provide and reiterate the missing context to the article.

Some docs & info about BDD/Behat
Submitted by Anonymous on Fri, 2013-02-15 12:59.

Official site
http://behat.org/

Docs
http://docs.behat.org/

Mink extension
http://extensions.behat.org/mink/

Make sure you install it using composer please me your life easy, do not forget to add mink extension & selenium driver in order to run at the browser, sample of my composer.json

{
    "require": {
        "behat/mink": "1.4@stable",
        "behat/mink-goutte-driver": "*",
        "behat/mink-selenium2-driver": "*",
        "behat/behat": "2.4.*@stable",
        "behat/mink-extension": "*",
        "phpunit/phpunit": "3.7.*"
    },
    "minimum-stability": "dev",
    "config": {
        "bin-dir": "bin/"
    }
}

Also my behat.yml

default:
    extensions:
        Behat\MinkExtension\Extension:
            base_url: http://local.dev/
            goutte: ~
            selenium2: ~
            browser_name: chrome

Once you load https://github.com/Behat/MinkExtension as mentioned in previous comments in order to see the list of available step definitions you can try

$bin/behat -dl

If you are using selenium do not forget to tag your scenario as javascript

@javascript
  Scenario: lorem ipsum

Never tried BDD/Behat on Drupal only for Symfony but very temped to do try http://drupal.org/project/drupalextension

Best Regards
Jesus | @jmolivas