On the Codeception blog there's a new post that advocates getting on the testing ship even if the project you're currently on isn't using tests (or TDD).

In this blogpost we will try to figure out how to get faster into the testing. What tests to write at first? Let's say we already have a project and we didn't practice TDD/BDD developing it. Should we ignore testing at all? Definitely no. So where should we start then?

They suggest a three-tiered pyramid approach - UI at the top, Integration testing in the middle and Unit testing as the foundation. They talk about the times when testing doesn't make sense, like when your application is based on a third-party tool (like WordPress or Drupal). They recommend starting with functional testing and working your way back down, especially if your framework supports it. Obviously they encourage the use of Codeception for it, but also recommend even something like Selenium tests if nothing else.

On the CodeCeption blog they have an example if how to use the testing tool to run headless with Selenium2 and PhantomJs to work with Javascript or DOM elements in the page.

The latest version of PhantomJS is an easy to install, stand-alone binary that doesn't require installing Node.js or any other dependencies, and ships with its own 'Ghost Driver' for implementing the WebDriver Wire Protocol. Which means you can drive it using the Selenium2 driver in Codeception, and anything that you can test in Chrome, Firefox, Safari, or IE using Selenium2, you can now test in half the time using PhantomJS.

They help you get the tools you need installed and show you how to start up the Selenium server and connect PhantomJS to it. Then you just run the acceptance tests for your application and get some feedback directly in the terminal window from the execution.

Headless testing can be a bit of a challenge, since it's impossible to 'see' what failed. But in this case, Codeceptions default logging and screenshot capture on failure can be extremely helpful, since you can then actually see the state of the browser at the point of failure.

On the Codeception site today there's a new post that compares their tool, Behat and PHPUnit for testing your applications.

This is guest post by Ragazzo. He uses Behat as well as Codeception for making his project better. He was often asked to do a comparison between Codeception, Behat, and PhpUnit. In this post he explains the commons and different parts of this products.

The author talks some about the difference between functional/acceptance tests and how they fit in with behavior driven development. He includes some examples of Behat test formats (Gherkin) and how it can be used for both the functional and acceptance side of things. He also talks some about why he prefers Codeception over Behat(+Mink) for his testing. A sample Codeception test is included, showing a login form check.

On PHPMaster.com today there's a new tutorial posted showing you how to use the Codeception testing tool to perform some acceptance/functional testing of your application.

What happens if you have more tests then zergs in the swarm? Really much more. You should find a way to control and manage them. In this article I'll share some hints and best practices you may use writing acceptance tests. I'll use Codeception testing framework to illustrate the best practices, but surely, they can be ported to any acceptance framework you use for testing.

He introduces the Codeception tool and some of the features it includes. He recommends using it to coordinate all of your testing as it can handle PHPUnit and Selenium tests as well as generate its own code coverage reports. He includes some code showing a basic test, making a request to a page, checking for contents and clicking on some links. He also shares a few design patterns using the tool - Page Object and Controller test examples.

The Codeception testing tool has released a new major update with some interesting new features - the expected feature for generating code coverage reports (similar to other tools) but there's also the idea of "remote code coverage" introduced.

There is no magic in local codecoverage. XDebug and PHP_CodeCoverage libraries do their job. The tricky thing is remote codecoverage. We attach small script into application's front controller. When a special header is sent this script starts to collect coverage information. And in the end of tests, this data is merged, serialized and sent back to Codeception. So you can test and collect coverage report even on staging servers in real environment.

They also mention a few other updates in the release - new Redis and MongoDb modules, UX improvements and the normal bugfixes. You can find out more about the code coverage feature in their manual or just about the project in general from the main site.

The Codeception project (BDD testing in PHP) has gotten a major update to its feature set and has bumped up to v1.1:

Many core classes were refactored to solve the common issues and reduce the level of dark magic inside. Only white magic left. And that's really cool 'cause you don't need to study to source code to implement your custom hooks now. Codeception is rapidly evolving to be the professional testing tool, ready to use by testsers and developers through out the PHP world.

Improvements in this large update include an update to the method of test execution, "grabbers" (helper methods that can extract content from tests), the introduction of XPath support to locate items in the content pulled into the test and the integration with unit testing. Upgrade instructions are also included.

Codeception, the PHP BDD (behavior-driven development) testing tool has announced some new features including newly updated documentation and support for Selenium2 and ZobmieJS.

Tools like ZombieJS, (PhantomJS, and more) are built in order to run tests without a browser. And so they are called headless. They don't require a browser window to start, they don't show any interactions on screen.

They briefly mention the "delay" option that's been introduced to allow for manual delays to be put into your code. You can find out more about this testing tool from its main project page or by just jumping in and reading through the docs. (You can also find the full code over on github.)

On the Codeception blog there's an introduction to the Codeception tool, a behavior-driven framework written in PHP (in the spirit of Behat).

How often do you see PHP projects with no line of test written? From my experience, this situation happens quite often. We should state the unpleasant fact that tests are not so popular around the PHP world. Surely, the advanced developers with 5+ years of experience in PHP and other programming languages understand importance of testing and PHPUnit usage. But juniors and seniors are just skipping testing and, therefore, produce unstable web applications.

A code example of the framework in use is included in the post - a test on a class using methods like "wantTo", "amOnPage", "fillField" and "click". The installation is pretty simple and it gives you a quick way to start working on acceptance, functional and unit tests. In BDD fashion, the tests are written in a more "natural language" than traditional unit tests making them easier for the non-developers (like QA) to write. Their example loads a page, fills in some form fields and submits the form to check the result.