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 NetTuts.com today there's a new tutorial showing you how to use ParaTest for PHPUnit to execute your tests in parallel instead of the usual inline, in-order method.

PHPUnit has hinted at parallelism since 2007, but, in the meantime, our tests continue to run slowly. Time is money, right? ParaTest is a tool that sits on top of PHPUnit and allows you to run tests in parallel without the use of extensions. This is an ideal candidate for functional (i.e Selenium) tests and other long-running processes.

ParaTest operates as a separate binary that can easily be installed via Composer. They walk you through the install and show you what kind of options it lets you provide (like number of processes and the path to the PHPUnit executable). They show you how to write some parallel tests, five of them, each that sleeps for a certain amount of time. They also look at another tool that could help run your tests in parallel, Paraunit. They finish off the post with a look at some functional testing examples using Selenium, handling race conditions and some of the future plans for ParaTest's future.

Andrew Podner has a posted the second part of his series looking at functional testing in PHP applications with Selenum.

In the first post about functional testing, we went through the basics of what functional testing is and how it complements and differs from other types of testing used for software quality assurance. This time, I will spend some time talking about using functional testing in a practical sense to set up a testing suite for a web based software project. [...] Each of these can provide a powerful means of performing automated functional testing and you should select your tool of choice based on what works best for you. I typically find myself using Selenium for functional testing, but again, I would encourage you to look at each available option out there and select the best fit

He walks you through the installation of the Selenium Firefox plugin, some of the basics of its use and how to create and run a simple test. He also looks at a slightly more complex example - filling in a form and validating the resulting page.

On the PHPClasses.org blog today Manuel Lemos has shared some advice on tracking and fixing bugs and some strategies to help prevent them in the future.

No matter how hard you try to test your PHP applications before putting them in production, you will always ship code to your server that has bugs. Some of those bugs will be very serious and need to be fixed before they cause greater damages to your application data that may be too hard to recover. Read this article to learn about a several good practices that you can apply to track bugs in production code, so you can fix them before it is too late.

Suggestions included in his list are things like:

• Test as Much as Possible Before in your Development Environment
• Separate your Code from Environment Configuration files
• Track PHP Errors with Assertion Condition Tests
• Send PHP Errors to an Error Log File
• Monitor the PHP Error Log File to Quickly Fix Serious Bugs
• Fix Your Bugs but Never Edit Code on the Production Server

He also includes a brief look at some things to think about when considering "defensive coding practices" and links to other articles with more information.

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.

In this new post to his site Michaelangelo van Dam looks at user acceptance testing with PHPUnit and Selenium.

Last week I spoke at php[tek] 2013 where I explained to people how to get started with Selenium IDE to record user interaction with the web interface, convert them to PHPUnit testcases and automatically execute them on multiple browsers on multiple platforms. The twitter I also received a bunch of questions regarding how to set up multiple platforms and why I used Windows in my presentation to deploy to. So today I deceided it was time to write a full article on this subject.

He introduces Selenium and what kinds of things it can be used to test. He also defines "user acceptance testing" and talks about why they're an important part of the testing ecosystem. He then walks you through the process of getting the testing environment set up, creating a few tests and how to convert them over to PHPUnit tests (using a built-in tool). Screencasts show you each step of the way. He includes a little tweaking you'll need to do to to the test code to get it working with your own Selenium server

In her latest post Anna Filina proposes that full test coverage is an impractical way to measure the quality of your software. It can provide a false sense of security, even if the tests are poorly written.

Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter.

She looks at how it's impractical to expect that all tests will be written efficiently or even correctly. Even simple tests are enough to show up on code coverage reports but may only be painting part of the picture. She also notes that not all software can be tested the same way - things like APIs require different testing skills/methods than something like consumer software.

In the end, there are no exact rules on how much to test. The most important thing to keep in mind is that writing tests for the sake writing tests is futile and costly. [...] Focus on building great software. Tests are a tool to make it better. Just don't overdo it.

On the Engine Yard blog today they've posted a conversation about testing between Ed Finkler and Chris Hartjes (also the hosts of the DevHell podcast).

Our friends Ed Finkler and Chris Hartjes recently had a chat about testing in PHP. Read on to get the low down on different testing tools and their relative merits-check it out as Ed and Chris weep for the future, come to some interesting conclusions and get their hands dirty so you don't have to.

They talk some about the current tools for unit testing in PHP applications and show what a sample test looks like. Ed talks about how the current testing tools can make it intimidating for people to get started testing and mentions the built-in testing library in Python that is a bit easier. There's also some mention of acceptance/functional testing and the Behat + Mink combo.

Andrew Podner has posted the first part of a new series to his site today. He'll be looking at using functional testing to improve quality of the resulting code and full application.

For this week, I wanted to focus on some different types of automated testing other than unit testing that can help developers build more robust applications and improve both the speed and effectiveness of quality assurance. Specifically, this post is going to focus on functional testing. Functional testing is composed of the tests that you write which are from the user's point of view. A functional test is used to perform quality assurance on all or part of an application utilizing the user interface as a pathway to the application.

He gives some examples of functional tests like clicking on buttons, trying a login, checking that the contents of the page are correct. He talks some about the purpose of functional testing and how it differs from unit testing. He suggests the metaphor of a race car - the pit crew would be the "unit testers" and the driver would be the "functional tester", saying whether or not all of the parts of the car are working together as they should for the race. In the next part of the series, he'll talk some about the actual software to automate this process.

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.