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.

Giorgio Sironi has a new post to DZone.com today about some of his experiences with Behat, a behavior-driven development testing tool written in PHP. It uses the Gherkin language syntax to define its tests.

I had the occasion to try out and adopt Behat for a particular need in our projects at Onebip. Here is my recount of the experience from a PHPUnit contributor and invested person.

He starts off with a list of situations where he doesn't think that Behat is a good fit for testing including testing of a single object and acceptance tests where comparing the response from more than one test is needed. He suggests that it's more useful for verifying high level business rules than anything. He talks some about the shift they made to using Behat and some of the benefits they found in its use. He finishes up the post by looking at the technical side and includes a warning about letting the size of the FeatureContext file get too large.

Luis Atencio has posted the third part of his continuous delivery series (parts one and two), this time with a focus on continuous integration as a part of the process.

This is a continuation from my previous post and overall the series on Continuous Delivery. If you haven't been following, that's okay, every topic is self-contained, so read along. The contents of these posts are taken from the book titled "Continuous Delivery" by Humble and Farley (resources below) overlaid with my own professional experience. In this article, we talk a bit more about Continuous Integration (CI) and some practices developers should follow to ensure a smooth environment.

He talks some about what "continuous integration" is and how much it relies on an automation of the process around your delivery of software. He mentions integration of testing (unit/acceptance/integration) and how it can help discover issues early. He includes a list of essential practices that come along with the idea of CI integration including:

• Don't check in on a broken build
• Keep a stable build at all times
• Anticipate being able to revert your changes
• Using TDD
• Distributed Version Control

He also recommends using any downtime (like waiting on a build to "go green" again) to take a few minutes away from the code - it can benefit you and your code.

Luis Atencio has continued his series on continuous delivery with this second post. It focuses on the first step (and one of the most important) - keeping everything configuration-related in a version control system.

I will be continuing the topic on Continuous Delivery which began in my previous post: Notes on Continuous Integration; this time we will start looking at the first and most important step, Configuration Management. In the words of the authors (resource below): Configuration Management refers to the process by which all artifacts ... and the relationships between them, are stored, retrieved, uniquely identified, and modified.

He sets out four principles that can be used to set this process up in your workflow:

• Keep everything in version control
• Manage dependencies
• Manage software configuration
• Manage environments

Each point has an explanation and advice on what he's found the best way to implement the functionality. He finishes with a few other pieces of advice including avoiding branching in config repositories and having good communication practices with your ops team.

Anthony Ferrara has written up a new post to his site looking at efective use of CSRF tokens and a few different strategies for generating them.

There's been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There's been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I'd write a post to explain WHY I agree with it.

He starts with an overview of a few of the common types of request forgery including from a javascript injection, a Man-in-the-Middle attack and a replay attack. He then breaks up the "lines of defense" part of the post into three different sections - adding a hidden token field to forms, changing the token for each request and using random numbers when regenrating them.

In a new post to his site Luis Atencio talks some about one of the things many development groups strive for but have a hard time achieving - continuous delivery of their application.

In the rapid changing software world of today, companies and individuals have come up with many methods in order to minimize the time to market gap, i.e the time it takes for your idea to materialize in production. Specially in the very competitive world of mobile and web applications. [...] We want our Operations team to be able to deploy correct and tested code in a manner that is automated and not stressful. [...] However, there is a down side to this: while it is important to beat the market and be innovative, it is also equally important to do this with a process that allows you to have a reliable product release.

He introduces the concepts behind "continuous delivery" and includes an illustration of how the flow would commonly work. He also mentions some benefits to implementing this into your project's flow including easy auditing and versioning, quicker deployments and the creation of a simplified, unified deployment system across platforms/environments. It's not without its challenges, though, so there's a bit of discussion about those as well.

Anthony Ferrara has posted his latest video tutorial in his series, this time covering dependency injection (mostly the concepts, not the implementation).

This week, we're going to talk about the topic of Dependency Injection in Object oriented code (specifically PHP). You don't need a fancy container to do it, it's actually quite simple to do manually!

He also talks some about the difference between a dependency injection container and a service locator. This is just the latest in his video series - he has others covering things like prepared statements, encryption and references in PHP.

On the Pro Developer site today there's a new post looking at the past and future of FuelPHP a framework started by Dan Horigan and Phil Sturgeon (who have both since left the team).

FuelPHP was first framework which used namespaces and was production ready at the same time. Small footprint, flexibility, namespaces, modularity and other gears make this framework great for building web applications. [...] For FuelPHP team 2012 was year with ups and downs. Dan Horigan was not available for his team members few months and no one didn't know where he was. He show up on the twitter and then he was unreachable again. WanWizard (Harro Verton) and Jelmer Schreuder were most active at the building FuelPHP core and they done a great job.

He takes a look at the road ahead (FuelPHP v2) and the work that's already been done on it. He also notes that another of the core team members has left the FuelPHP development group a few days ago and that there were some things about the framework he no longer liked. The post suggests looking into something like Laravel (v4, not yet released) if you're shopping for a new framework. He does note that, while the future of FuelPHP may be rocky, it is a stable framework and is still a solid choice for a platform (especially if it's already in use).

Timothy Boronczyk has written up a new post that looks at using assertions in PHP - the actual use of the assert function to evaluate values in your code.

I stumbled upon assertions in PHP today, though why I didn't know they existed after working with the language for so long and what I was looking for originally when I came across them are both mysteries. And with the increasing focus on software quality in the PHP community, I wondered why I hadn't seen them used by others. I decided to ask around, look into PHP's implementation of assertions, and do some tinkering.

He talks some about their usage, some of the common issues surrounding them and compares using them directly on return values vs evaled strings. He also includes an implementation of them in a bit of sample code - a class that uses them (and an assertion callback) to handle the throwing of exceptions.

Assertions are meant to identify program logic/design bugs, not as a run-time error handling mechanism. Isn't this why we do unit testing? Playing devil's advocate, what's wrong with pushing unit tests directly into your code if we have doc comments that are extracted for documentation?

On NetTuts.com there's a recent post that tries to explain the "whens" and "whys" of design patterns - when using them is a good idea and why you might want to implement them as a part of your application.

There are plenty of articles that explain what design patterns are, and how to implement them; the web doesn't need yet another one of those articles! Instead, in this article, we will more discuss the when and why, rather than the which and how. I'll present different situations and use-cases for patterns, and will also provide short definitions to help those of you who are not so familiar with these specific patterns.

They've broken them up by topic instead of by the patterns themselves with sections like:

• Finding the Data We Need
• Reusability
• Discover-ability
• Singularity
• Controlling Different Objects

There's also a few sections that look at other patterns that really only have a handful of uses - like the Decorator, State and Composite patterns.