On the Delicious Brains site Ian has written up a lengthy post sharing how they automate their acceptance testing for their PHP applications.

Have you ever had the joy of carrying out acceptance tests? For our team at Delicious Brains, testing our releases, in the past, has been one of the most dreaded tasks on the to-do list. We hold our plugins to a high quality standard so it’s a must but manual tests are brain-numbingly tedious and can take hours of expensive developer time.

Recently, we decided it was high-time to fix that. [...] Read on for more about how the automation of testing our plugins ahead of release is shaping up – including how we manually tested in the past and a look at some of the automated acceptance tests we’ve already implemented.

He starts by defining what acceptance testing is and how they're different from other types of testing. He then shows the manual method they were using to run their tests previously and what prompted the move towards automation. He talks about the tools that they use for their automated testing including Codeception and Docker. Configurations and scripts are included that make the automation work and some of the issues they came across during the move from manual to automated processes.

The Codeception blog has recent post they've written up talking about writing better tests for your application and the difference between expectation and implementation as it relates back to meaningful tests.

What makes a meaningful test? This question should always be asked. No matter we write your tests first or tests after, they may stay in a project for years and it is pretty important them to test the things that really matters. Badly written tests can slow us down by constantly failing on each implementation change, and such tests can be written no matter you follow TDD or not. The idea of a test is to ensure that software works and not to freeze it at specific point.

Such situation happens when a test is bound to implementation details. [...] But how to understand what is stable and what is not? We need to use interfaces. Not that one which is written as interface keyword in PHP but a general term: User Interface, API. And that’s what makes unit testing and browser testing similar: we always need to rely on public interfaces for a test.

They give an example of a test that's "bound to implementation details" from the Magento codebase that relies on a specific function implementation (the "makdir" method). This function is a part of the Symfony functionality, not Magento, and what might happen if things change in your application. They note that the main difference is testing for the result versus testing for the behavior of the functionality. The tutorial wraps up by suggesting that the only testing that should be done is on public, well-defined interfaces that are not as subject to change and not copying logic into tests.

TutsPlus.com has continued their series looking at programming with the Yii2 framework with this new article covering testing the application with Codeception.

In this Programming With Yii2 series, I'm guiding readers in use of the Yii2 Framework for PHP. In this tutorial, I'll explore automated testing using Codeception, which is integrated with` the Yii2 development framework.

Admittedly, my experience writing tests with my code is scarce. I've often been part of solo or small projects with limited resources. During my time at Microsoft, we had distinct test teams that did this. But frankly, this is likely typical of you too, right? Programmers like to code, they don't write tests—at least old school programmers didn't.

He briefly talks about some of his own experiences with Codeception and how it "makes writing tests fun and easy". The tutorial then moves over to the technical side, showing how to install the Codeception tool and set up the Yii2 application to integrate with its testing functionality. The remainder of the tutorial is split up into the different kinds of testing (unit, functional and acceptance) and some code examples of each.

The Master Zend Framework site continues their series covering the creation of a Docker-based testing environment in this second part highlighting the addition of testing support.

In the first part in this series on developing web applications using Docker, we saw how to create a local development environment using Docker; one ideally suited to creating Zend Expressive (or any other kind of PHP-based web application). But, what we didn’t cover was how to handle testing in a Docker-based environment.

[...] How do you run tests when working with Docker containers? After a bit of searching, I found that it’s not that difficult. But you have to use the right combination of commands.

Since unit tests can be run locally if need be (they shouldn't need any resources from the service if they're true unit tests) he focuses on acceptance testing. For his examples he uses the Codeception testing tool. He walks you through the setup of some simple tests based on the "home" page functionality of the Zend Expressive skeleton application. With that in place, he shows the updates that will need to be made to execute the tests from outside the instance via a "docker exec" call. The post finishes with a look at adding two other tools to the mix as well: Make and Phing.

The Toptal.com blog has posted a new tutorial that wants to help you make the most of your application via testing. They show you how to use Codeception to create a set of tests to ensure your application is working as expected.

Before moving on to Codeception and PHP, we should cover the basics and start by explaining why we need testing in applications in the first place. Perhaps we could complete a project without wasting time on tests, at least this time?

Sure, you don’t need tests for everything; for example, when you want to build yet another homepage. [...] However, you definitely do need testing when: your team uses BDD/TDD, your Git repo contains more than a couple commits, [and] you are a proper professional, working on a serious project.

They start with a look at the kinds of things testing solves in your development process and the different kinds of tests you can create. From there they introduce Codeception, an alternative testing tool to the widely used PHPUnit. The tutorial helps you get it installed and shows you how to make a simple, first test. It helps you execute the test, debug issues that might pop up and the different assertions you can use. With the fundamentals in place, they move on to more details on using it for functional and unit testing.

Mohamed Said has written up an article about acceptance testing a Laravel+Vue.js application with the help of the Selenium WebDriver functionality.

The good thing about writing tests at a mature stage of the project is that many of the basic parts of the application are settled down, major changes have slowed, so deciding the shape of tests can happen in a more solid way. Testing too early, in my opinion, leads to the need of changing tests whenever you change functionality, so it’s work * 2.

This post is about a single type of tests and I think it’s the most interesting one.

He starts with a brief description of what acceptance testing is for those not familiar with the concept. He then gets to the Selenium WebDriver, provides a summary on that as well and points out the main tool they use for their tests: the Javascript driver it provides. the syntax on the driver is a bit difficult to follow so they also suggest layering Nightwatch.js on top to make for simpler, cleaner and easier to read tests. There's also information and (acceptance) testing the backend of the application with various tools, ultimately deciding on the use of Codeception.

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.

Hafiz Waheeduddin Ahmad has a new post to his site, part three of a series he's posted on API testing, looking at the use of Codeception for testing API output and functionality.

In this post, we will have a look on how we can use Codeception for API testing.

He starts by helping you get Codeception installed through Composer through a "require" command line call. He then walks you through the setup of the project and how to use the "codecept" command line tool. He covers the generated directory structure the bootstrapping created and how to set up a sample configuration for your API. He then gets into writing an example test, showing how to check things like authentication, HTTP header information, response codes and response contents. Finally he shows how to run the tests in both a normal and more verbose way.

If you're a Codeception user, you'll find Matthew Turland's latest post interesting. In it he shares a way to customize database cleanup between the tests. Codeception handles it a bit differently that how PHPUnit's Db module does.

Recently, I was looking into ways to speed up the runtime of the test suite at Blopboard. We use the Codeception framework to write functional tests for our REST API, part of which entails putting the database into a known state using Codeception’s Db module. The behavior of this module is similar to that of the PHPUnit Database extension with one exception: where PHPUnit only truncates tables and leaves their schemas intact, Codeception removes the database structure and expects the SQL dump it uses to recreate it between tests. I must admit to not understanding this design decision of Codeception, nor attempts to clarify it.

He admits that his solution is "a bit hacky" but it does work to truncate the table rather than drop the entire schema and wait for a rebuild. His "DbHelper" class is used in place of the Db module. He traced through the execution path of the Db module and found a "hook" where he could override the "cleanup" method to prevent the schema drop and replace it with a truncate. He also includes code for a suggested addition to Codception that would handle the same thing in a more integrated way.

On NetTuts.com today there's a new tutorial posted from Andrew Perkins about acceptance testing with Codeception, an alternative testing framework that's been gaining popularity in the PHP community.

Codeception is a multi-featured testing framework for PHP. It can handle unit, functional, and acceptance testing of web applications and it’s powered by the already very popular PHPUnit testing framework.

Codeception allows us to test different kinds of user perspectives and site scenarios while they are visiting our app to ensure a pleasant user experience. By testing multiple scenarios, we can simulate a user’s natural flow throughout our application to make sure the app is working as expecting.

The tutorial guides you through the process of getting Codeception up and running and creating a first test. The example test hits a basic PHP-enhanced HTML page to uppercase a given string. They show how to create the test skeleton and flesh it out with a test for the page load as well as the form submission.