I am working on a project where I am writing some custom Behat steps, as the steps that come pre-defined with Behat, Mink and the Drupal Extension are simply not adequate for user friendly scenario steps. The step I just wrote and tested, which is fairly simple but makes writing scenarios for this particular project much easier, allows you to look for the presence of a form within a region of a page using its HTML ID or HTML name, and is outlined here.
I recently started using Behat for User Acceptance Testing with some of my client projects, and just ran across a very extremely useful snippet in the Behat Documentation, for automatically adding the Behat generated method stubs for custom steps to your FeatureContext class file.
Last week, I presented at the Chattanooga Drupal Users Group meeting on User Acceptance Testing with Behat for Drupal. Here's a link to the presentation, which Adam Jimerson captured using Google Hangouts.
This post is part of my "Continuous Integration on a Budget" series, and covers the "whats" of Behat and other tools available to implement Behavior Driven Development as part of your Continuous Integration process.
This post is part of my "Continuous Integration on a Budget" series, and covers setting up a Jenkins Template for Drupal Testing on a Jenkins CI server which, in this series, is set up on a Linode instance running Debian 7
Test Driven Development, Continuous Integration, Automated Testing, Automated Deployment ... sounds wonderful, doesn't it? Perhaps a bit daunting?
"But I'm a small Drupal developer running my own development shop. I don't really have the time or the tools for that."
I thought that too. However, after spending countless hours chasing down obscure bugs in code I (or, in many cases, someone else) wrote weeks (or months) ago that is now behaving badly because recent modifications in the codebase changed its behavior, I began to think, "There has to be a better way".