On the SitePoint PHP blog editor Bruno Skvorc has written up a tutorial about using the Peridot tool to do BDD style testing but on the units of code rather than the behavior of your integrated application (your business logic).

We’ve done our share of testing posts here at SitePoint, with more coming soon, but I wanted to show you a relatively new testing tool I found that caught my attention because of how unconventional it seemed.

Peridot is a BDD testing framework (so behavior driven testing) but for your units of code – not your business logic. Wait, what? Yes.

He gives an example of the test structure and how a similar kind of test would reduce down to assertions evaluating your units of code. He also includes an example of Peridot's human-friendly output for both passing and failing tests. He goes on to talk about the concurrency the tool allows, the feature to focus on/skip certain tests, use events and plugins, and output a code coverage report. Several more features are also discussed including custom scopes and the ability to define custom DSL definitions you might find easier to work with in your testing.

On the php[architect] site there's a new tutorial posted from Oscar Merida about testing Drupal sites with Behat, a popular PHP-based "Behavior Driven Development" testing tool to help ensure your application is performing correctly from the outside.

If automated testing is not already part of your development workflow, then it’s time to get started. Testing helps reduce uncertainty by ensuring that new features you add to your application do not break older features. Having confidence that your not breaking existing functionality reduces time spent hunting bugs or getting reports from clients by catching them earlier.

Unfortunately, testing still does not get the time and attention it needs when you’re under pressure to make a deadline or release a feature your clients have been asking for. [...] After reading all the theory, I only recently took the plunge myself. In this post, I’ll show you how to use Behat to test that your Drupal site is working properly.

He starts by listing some of the requirements you'll need to get started (packages installed via Composer) including the installation of a Drupal specific plugin to make testing these sites easier. From there he shows how to configure the Behat tool and write a simple feature to test the visiting of a certain page and looking for matching results. He also includes tips about testing with user authentication, using custom contexts and Selenium integration.

The Master Zend Framework site has posted the second part of their tutorial series showing how to test Zend Framework applications with CodeCeption, a tool allowing for behavior-driven testing methods on PHP applications. In part two of the series they finish up the examples from part one and put them to use.

In part one of this series on testing Zend Framework applications with Codeception, we covered what Codeception is, how to install and configure it, and how to enable and configure the Zend Framework 2 module; finishing up by writing some basic acceptance and functional tests. [...] Here, in part two of the series we see how to retrieve and test registered services using BDD-style testing. This isn't going to be an exhaustive look at every possibility of what's available. Instead, what I'm going to do is show a simple set of examples which use two extra modules which come with Codeception and how they enable descriptive, BDD-style, tests.

The tutorial starts by getting into a bit more detail on what BDD-style testing is and some of the basic terminology. They help you install two modules to help make writing your tests simpler. The tutorial walks you through generating a new test for a fictional "Video" table gateway class and how to flesh it out to pull the service from the service manager, configure the database connection and write a few checks to verify the type of the service fetched and the number of records it returns.

Bruno Skvorc has written up a tutorial on the Semaphore-CI blog showing you how to get started with behavior-driven development in Laravel applications. He makes use of the Behat and PHPSpec libraries to write and execute the tests.

For many developers BDD is a complicated subject, and getting started with it the right way often does not come easy - especially when you need to implement it into an existing framework. This tutorial aims to help you get a BDD-powered Laravel project up and running in very little time, introducing you to the basic concepts and workflow you'll need to proceed on your own. We'll be installing and using Behat and PhpSpec.

He walks you through the process of getting everything you need installed: a simple Laravel application and Behat (also requiring a bit of setup to make it "play nice" with Laravel). He initializes the Behat directory and explains the concept of "context" and how to configure your Behat installation. He then gets into writing the features, creating a basic test that checks the main page of the Laravel application for the phrase "Laravel 5". A bit of additional PHP code is required to make the tests work (included) and the result is a passing test, executed with just a behat command.

The second half of the article is about PHPSpec, showing how it can be used as a sort of replacement for PHPUnit with a bit more readable syntax. He shows how to write a simple test against an object. Finally, he shows how to combine the powers of Behat and PHPSpec into a single method of testing, using PHPSpec behind the scenes in the Behat context to help with testing assertions.

In a new post Marc Morera makes a suggestion for a testing practice to add to the use of the popular BDD PHP testing framework Behat - a "data-test" option to help with decoupling the tests from implementation.

Tests should be as robust as possible. I think you will agree with me with that phrase. If your tests are too coupled with your implementation, a simple modification of your code will need the modification of your tests, and that’s so annoying, right? [...] My question is… should the frontend of your website be aware of the how your Behat tests are built? In my opinion, nope. Your tests should live in a simple layout on top of your application, emulating some cases and ensuring that your users will be able to do what they should be able to.

He points out the main problem with the current testing methods, mainly that the real issue is in the hard-wiring of the test functionality to the name/id/type of the interface elements. He also brings up the aspect of translations and ensuring that your tests take into account that the text may not always be in English. He also mentions Symfony forms and how they define their own structure and naming, not necessarily what you manually generate. He instead proposes a "data-test" property that could be added to elements both indicating that they're used by the testing process and can help in locating the elements during the testing process.

The latest episode of the Full Stack Radio podcast, episode #15, features a focus on Behat (the PHP BDD testing tool) and an interview with its creator Konstantin Kudryashov, aka everzet.

In this episode, Adam talks to Konstantin Kudryashov, creator of Behat and BDD Practice Manager at Inviqa. Konstantin and Adam talk about the schools of TDD, how to use test doubles effectively, and common challenges people face when trying to learn TDD.

They talk about several other subjects besides just BDD too including the book "Test Driven Development: By Example" and Ian Cooper's talk "TDD: Where did it all go wrong?". You can listen to this latest episode either through the in-page audio player or by grabbing the mp3. If you like the episode and want to hear more, be sure to subscribe to their feed too!

On his site today Jani Hartikainen has a new post helping to demystify some potential confusion around unit testing, test-driven development and behavior-driven development. He's talking about them in the context of Javascript in this case, but the fundamentals transfer to just about any other language, including PHP.

When you’re just getting started with automating your JavaScript testing, there’s a lot of questions. You’ll probably see people talk about unit testing, TDD or Test-Driven Development, and BDD or Behavior-Driven Development. But which one of them is the best approach? Can you use all of them? I’ve talked to a number of JavaScript developers, and there seems to be some confusion about all this. So, let’s take a look at Unit testing, TDD and BDD, and fix some of the common misconceptions about them out there.

For each he provides an overview of this basic concepts and a bit of sample code showing it in action. For TDD (test-driven development) there's not really a way to show it specifically in code as it's more of a practice. Instead he gives a "checklist" to follow when practicing it.

Unit Testing gives you the what. Test-Driven Development gives you the when. Behavior Driven-Development gives you the how. Although you can use each individually, you should combine them for best results as they complement each other very nicely.

NetTuts.com has posted the second part of their "Laravel, BDD and You" series (part one is here) building on their introduction in part one and building a first feature (what BDD tools call their tests).

In the second part of this series called Laravel, BDD and You, we will start describing and building our first feature using Behat and PhpSpec. In the last article we got everything set up and saw how easily we can interact with Laravel in our Behat scenarios. [...] In short, we are going to use the same .feature to design both our core domain and our user interface. I have often felt that I had a lot of duplication in my features in my acceptance/functional and integration suites. When I read everzet's suggestion about using the same feature for multiple contexts, it all clicked for me and I believe it is the way to go.

He starts in with the creation of the first feature - a simple "welcome" test that evaluates the main Laravel start page. He uses this example to set up a Laravel trait that can be reused in other parts of the testing and how to use it in a Feature Context file. He then starts to create the tests for the sample time tracking application started in part one. He gives an example of the feature file's contents, the result from its execution and the "small refactors" that it will suggest to add functionality to the feature file. With this skeleton in place, he then fleshes out the test to make it actually work with the requests. He walks through each function and provides the code needed for both the test and other tools/objects they need.

On NetTuts.com they've kicked off a new series of tutorials teaching you about Laravel development but using the principles and testing of behavior-driven development (BDD). In this first part of the series they get you started with the basic environment and a few simple tests.

Welcome to this series about developing Laravel applications using a behavior-driven development (BDD) approach. Full stack BDD can seem complicated and intimidating. There are just as many ways of doing it as there are developers. In this series, I will walk you through my approach of using Behat and PhpSpec to design a Laravel application from scratch. There are many resources on BDD in general, but Laravel specific material is hard to find. Therefore, in this series, we will focus more on the Laravel related aspects and less on the general stuff that you can read about many other places.

He talks about what it means to "describe behavior" versus other kinds of testing and introduces the sample application they'll be creating to show these principles: a time tracker. Following this, they help you install the needed tools (via Composer) and initialize the directory to be ready for the Behat/Phpspec tests you'll create. An example of a basic Feature is included, testing the initial Laravel "Welcome" page it defaults to and how to execute it. Finally, following the ideals of BDD, they show how to implement the "Given I am logged in" step first in the test then in the Laravel application.

The NetTuts.com site (well, TutsPlus) has posted a new tutorial that gets you more intimate with PhpSpec, a PHP-based testing tool that lets you define tests as specifications and using behavior-driven development principles. If you need an introduction to the tool, check out this other tutorial first.

If you compare PhpSpec to other testing frameworks, you will find that it is a very sophisticated and opinionated tool. One of the reasons for this, is that PhpSpec is not a testing framework like the ones you already know. Instead, it is a design tool that helps describing behavior of software. A side effect of describing the behavior of software with PhpSpec, is that you will end up with specs that will also serve as tests afterwards. In this article, we will take a look under the hood of PhpSpec and try to gain a deeper understanding of how it works and how to use it.

They provide a quick overview of some of the internals of the PhpSpec tool and a brief look at the difference between BDD (behavior-driven) and TDD (test-driven) development practices. There's also a look at how the tool differs from the popular PHP testing tool PHPUnit. Code examples are provided through out the post with simple tests, making the separation between the methods and tools easier to follow.