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.

Anthony Ferrara has a new post to his site today describing what he sees as a failure in our industry - letting security become an after-thought to the development process.

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.

Phil Sturgeon has posted a guide to his site about running tests and contributing back to packages that live in Composer.

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.

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.

In his previous post ("PHP was meant to die") the point was made that PHP isn't really designed as a language to handle long running processes very well. It's made to handle a few operations and then die at the end of the request. In this follow up post he talks more about using PHP for long running processes and a library that could help.

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.

Luis Atencio has posted the latest article in his "Continuous Delivery" series today, this time with a focus on implementing a testing strategy. This is the fourth post in the series (part 1, part 2 and part 3).

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.

Matthew Setter has a new article on his MaltBlue site today that suggests that one of the reasons a project is successful is because of effective testing.

Like many of us, despite being told repeatedly how great testing is, the benefits it will bring, the time it will save and how it will improve the quality of my applications, I too considered testing a second-thought. I saw it as something which was both expensive and time-consuming. If I was genuine with you, I'd say I believed it be be nothing more than a "nice to have", after the application was written. If you also feel (or have felt) this way - know that you're not alone.

He realized, though, that the usual false assumptions about testing were just that and starteed getting into testing, TDD and BDD on recent projects. He talks some about some general thoughts around testing like "testing can't be an after-thought" and the fact that it's no always easy. He includes a way of thinking about testing in your application and the confidence good, solid tests can bring.

NetTuts.com has posted a new article for the Laravel users out there - a tutorial showing how to test Laravel controllers via PHPUnit tests.

Testing controllers isn't the easiest thing in the world. Well, let me rephrase that: testing them is a cinch; what's difficult, at least at first, is determining what to test. Should a controller test verify text on the page? Should it touch the database? Should it ensure that variables exist in the view? If this is your first hay-ride, these things can be confusing! Let me help.

They break up the testing process into three main chunks - isolation of the tests (mocking where need be), calling the controller method and running the checks (assertions) to be sure the result is valid. They start with a basic controller test that runs a GET request on the "posts" method. They also mention the assertion helper methods included with Laravel controller testing, things like "assertRedirectedTo" and "assertSessionHas". The article then gets into moreo practical examples showing a TDD approach to testing some simple controller calls, mocking data connections, handling redirects and repositories.

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.