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.

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.

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 Script-Tutorial.com site today there's a new post looking at functional programming in PHP - some of the concepts involved and example code showing how to make it work.

Functional programming can be defined in simple terms as a programming paradigm that do not change the state of a program instead it uses pure functions. A pure function is a function that has the ability to accept a value and return another value without changing the input supplied to it. It is characterized by its ability to support functions that are of high order. [...] A programming paradigm that is functional has the following attributes: do not alter the states which make parallelism easier, deals mostly with a function which is the smallest unit hence enhances readability of code, has deterministic functions that enable stability of a program.

He talks some about anonymous/lambda functions (closures) and their role in PHP's implementation of functional programming. He also talks some about partial functions, currying, higher order functions and recursion. He finishes off the article with a look at some of the advantages this method of development can bring as well as some of the disadvantages that come with things like recursion and the learning curve of the method.

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 the Inviqa TechPortal today there'a a new post from Konstantin Kudryashov showing you how to use Mink for functional testing (an extension of Behat) of you web application.

Automated testing is big news these days. There's hardly a PHP conference happening without a talk on testing automation or derivative methodologies. TDD (Test-Driven Development) and BDD (Behaviour Driven Development) are all around us. So why should you care about all this? [...] The more complex an application becomes, the harder it is to be sure that each new feature or bug fix won't break the system, and that decreases your overall confidence in your work as developer. That's exactly the reason why you need automated testing - to be confident that you're not breaking important parts of an application.

For his examples he uses a simple Silex-based application (found here on github) that just shows a main page and an "add article" page that returns a preview when submitted. He shows how to get Behat/Mink installed and how to bootstrap PHPUnit to allow you to execute your tests. Also included is a sample test that clicks the "Add Article" link, runs a few checks and fills in some data. The form is submitted and the "preview" page is checked for valid results.

The QaFoo folks have posted information about a webinar they're putting on for those interested in using Behat for doing functional testing on their applications:

I've already written two blog posts here about Behat: Behavior Driven Development and Code Coverage with Behat. If that made you curious or you wanted to learn about Behat anyway, I can highly recommend to join the free webinar on Behavior Driven Development with Behat I'll be giving on May 8th 2013 on behalf of Qafoo in cooperation with Zend.

As mentioned, the webinar is free to attend, but you'll need to sign up to be able to attend.

Anna Filina has a new post to her site that helps to clarify the definitions between functional, unit and integrations tests of your application's functionality.

I have recently read a blog post claiming that functional tests are not "true" tests. The author also claims that unit testing shows you where the problem is occurring, while functional testing simply identifies that a problem exists. This argument is deceptive and the conclusion dangerous. Different kinds of tests are not mutually exclusive. One is not superior to the other. They have different goals and can happily coexist. Let me explain the kinds of tests so that you could make enlightened decisions.

She covers each type of test in detail, noting the goal of that particular type and some examples of the kinds of things they might test. She starts with the highest level, functional testing, then jumps down to the lowest - unit testing. She finishes up the post defining "integration tests" as tests that ensure you're integrating correctly - that you're using the API provided by the tool in the right way and that it's working as expected.

On the QaFoo blog today there's a post for those using the Behat testing tool showing a way to collect code coverage metrics based on your tests using the PHP_CodeCoverage library and phpcov.

There is generally no point in having code coverage for Behat test cases because of their nature: The purpose of an acceptance test is to assert a certain behavior of an application, not to technically test a piece of code. Therefore, there is no point in checking for uncovered code pieces in order to write a Behat test for it. That said, there is still a scenario where you want to peek at code coverage of Behat tests: When creating them as wide-coverage tests before starting to refactor legacy code. Behat in combination with Mink provides you with a great tool for such tests.

They help you get the tools installed and show the code you'll need to add to the application itself to collect the coverage data as the tests execute. It keys off of a file existing/not existing to know if it should execute the coverage or not. The phpcov tool can then be used to generate the HTML output of the coverage information for easy viewing.

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.