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

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.

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.

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.

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.

In the April issue of the PHPArch magazine (also published on her blog), Elizabeth Tucker Long wrote a really interesting editorial piece coining a concept she called Security-Driven-Development. She (quite correctly) identified a problem in the current development community where security has become an after-thought (if it's thought of at all). This isn't a new concept, in fact it's a concept that I and many others have been preaching for quite a while now. However I've been coming to realize that I've had it wrong the whole time. And I think the entire industry is getting it wrong today.

He talks some about the current state of web application development and how, even with more powerful technologies than ever, we still fall short in security testing. He suggests that the current way of doing things - treating security testing as a "throw it over the wall" or "someone else's job" problem - needs to stop. Security needs to be integrated with development and he suggests that managers and developers of open source projects should take the lead.

While Composer has been around for a while now, many packages are still in their infancy (< 1.0) or sometimes are just not as feature filled as they could be. To be fair there is always more to be done. It can always do more, or do the same thing more efficiently. Whatever the case, pull requests are going to be a common thing for the PHP community to be doing to these packages and this needs to be done safely, with unit-testing. So, how do you run their test suite and add your own tests?

He includes a step-by-step guide to getting the environment set up to run the package's tests and how to add some of your own. He includes the commands to send the pull request back up to Github (on your own fork, of course) and how to use that same fork as your package resource until the main project is updated.

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.

Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that's not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It's a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let's illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

There are three things in life that are always held to be true: we will die someday; we will pay taxes; and software will have bugs.... LOL [...] A testing strategy is often overlooked in software projects. This should not be too surprising, we want to build applications quickly and release them quickly. However, leaving quality out of the picture or towards the end are terrible mistakes.

He talks some about the different types of testing that revolve around software development - "business facing" and "technology facing." These are each split down even further into things like acceptance, integration and unit testing.