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.

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.

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.

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.

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.

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.

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.

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.

Many programmer like to talk about functional programming, but if you ask them if they've ever done it, most of their replies will be "No". The reason is quite simple: we are taught to think in an imperative manner when we first start learning to program, in terms of flow charts and steps to be followed in the program. So in this article I'll explain some important concepts to functional programming and how to write functional code in PHP.

He starts by defining some of the basic fundamental concepts of functional programming including recursion, referential transparency, higher order functions and lambda functions. He includes a bit of code along the way, showing things a bit more practically.

PHP has traditionally been a simple, procedural language that took a lot of inspiration from C and Perl. Both syntax wise and making sure function signatures are as convoluted as possible. PHP 5.0 introduced a proper object model but you know all of that already. PHP 5.3 introduced closures and PHP 5.4 improved closures very much (hint: $this is available per default).

He starts by defining functional programming for those not familiar with the concept. With this understanding, he looks at what PHP has to offer that will help make this definition a reality, things like call_user_func_array and closures. He includes some code examples comparing the PHP structures to other languages and their features (like Haskell and Ruby). The post also gets a bit more practical with a "real world" example of a script that calculates the totals from the set of items in a shopping cart using a helper library to do some of the basic functional handling.