Andrew Podner has a posted the second part of his series looking at functional testing in PHP applications with Selenum.

In the first post about functional testing, we went through the basics of what functional testing is and how it complements and differs from other types of testing used for software quality assurance. This time, I will spend some time talking about using functional testing in a practical sense to set up a testing suite for a web based software project. [...] Each of these can provide a powerful means of performing automated functional testing and you should select your tool of choice based on what works best for you. I typically find myself using Selenium for functional testing, but again, I would encourage you to look at each available option out there and select the best fit

He walks you through the installation of the Selenium Firefox plugin, some of the basics of its use and how to create and run a simple test. He also looks at a slightly more complex example - filling in a form and validating the resulting page.

In her latest post Anna Filina proposes that full test coverage is an impractical way to measure the quality of your software. It can provide a false sense of security, even if the tests are poorly written.

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.

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.

Matt Setter has a quick new post that suggests a way you can get more done with less work - simplicity.

Though we can do so many things simultaneously - should we? Does it actually reduce effectiveness and productivity which are the antithesis of professional application development? [...] I had the thought, as is common in a western-based mentality, that to be busy, to be industrious, to try and multi-task a series of independent tasks and projects simultaneously was the right thing to do. It's meant to be a simple formula: "Greater productivity = Greater self-worth right?" Sounds almost like Thatcherism. I felt that this was not only right, but the sign of an intelligent and sophisticated developer, who truly had honed his craft. Perhaps you've felt the same at one time or another?

He points out that, while it's very easy for developers to fall into this trap and way of thinking, it's not sustainable. It leads to stress, bad code and even - possibly - an even higher bug count. Instead he suggests the good standby idea of "KISS" (essentially, simplicity).

Instead of trying to do everything at once - I stopped and decided to only do one thing at once. And that one thing, had my full attention and focus. When it was done, I then moved on to the next one. Not before and not after.

He includes some of his own experience trying to apply this in a Zend Framework 2 application.

Eran Galperin has a new post to his site today talking about the real cost of software development, how it's more than just time spent hands-to-keyboard.

If you are a first-time entrepreneur and likely someone with little experience with software development, the chances of you successfully directing the development of a product on your own, are slim. [...] In software development, too often vision holders hand off a "vision document", i.e. "The Specifications", to a developer and expect him to translate it to the finished product they have in their mind. Most software developers or graphic designers are simply not fit for that role - they do not have the experience, skills or vested interest in transforming your vision to an actual product.

His examples revolve around the idea of outsourcing the development to another group, but a lot of the concepts still apply to in-house development too. He talks some about the idea of "you get what you pay for" when it comes to quality and how much you're willing to pay. He then gets into one of the hardest questions when dealing with development - how to find good developers. He mentions several things that need to be a part of that relationship like trust and good communication.

PHPMaster.com has a new article about a practice that's becoming more popular in recent years to help increase the quality of code that comes out of development - code reviews.

Every developer knows the pain of banal mistakes. A wrong attribute here, a misspelled property there, an accidentally duplicated line of code which you missed because of the coffee-fueled 16 hour hackathon you've been on. [...] Code review is simply the act of having someone else look at your code to find the mistakes you missed.

The tutorial talks about the types of code reviews (three of them with varying levels of involvement) as well as some best practices to follow in your reviews like:

• Know your common mistakes and actively fight them.
• Peer code review means being reviewed by someone of equal or greater skill.
• Collect metrics.
• Be mindful of the social aspect - finding bugs is good, not bad!

In response to some of the "problem with PHP" posts that have been circulating lately, Anthony Ferrara has posted about the "true problem" with PHP - less about the language, more about the community.

The core of the PHP community is filled with a lot of really talented and smart developers doing some really amazing things. But on the fringes, there are a lot of people who are writing articles, tutorials, and posts designed to help beginners learn the language (and usually how to program). The problem with this is that the majority of those authors frankly don't have a clue what they are talking about.

He talks about why this is a problem (bad practices promoted, bad code) and what you, as a PHP developer, can do about it...and maybe help in creating a separate tutorials site with content "approved" to provide good practices and quality code.

In case you missed it (there's been a good bit of buzz about it in the PHP community lately) there's a recent post from Jeff Atwood about the PHP language and some of his thoughts on its usefulness, it's structure and some of this thoughts on the usual "PHP sucks" kinds of articles.

Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP. This has been going on for years.

He talks about the the anti-PHP rants that have been happening (over and over) for years, his thoughts on it being the "worst designed mainstream 'language'" out there...and how the discussion doesn't need to be around these points anymore. It needs to be about how to get programmers to use better tooling (whether or not PHP is the right tool for the job).

Of course, there's no shortage of comments on a post like this, so be sure to go through them and see the various reactions to Jeff's thoughts.

In this recent post on Reddit.com, a developer asks the community about some of his feelings about bugs in his software and his focus on quality:

No one has told me this and I don't need them too. I feel like one bug that has a negative impact on the user experience is too many bugs. I've been programming for over 5 years professionally and I still introduce bugs into my code. [...] I don't like the expectation that I (and maybe others have) that my code must be perfect when I am not perfect. I don't like the fact that it only takes one mistake to affect so many people. [...] I'm wondering if others on here have every felt this way. What have you done about it?

Suggestions in the comments talk about everything from dealing with the apparent burnout the developer is facing, a reminder that no code is bug free and some recommendations of testing and bug tracking to help make the quality of the code better (and give visibility into the level of work being done).

On PHPClasses.org today they've posted their latest "Lately in PHP" podcast - episode 21, "Is PHP Source Quality really Good or is it still Insecure?".

A study from Coverity claims that the source code of Open Source projects such as PHP has a low defect rate. Meanwhile, a few weeks ago, the security expert Stefan Esser claims that PHP source security bug prevention has a lot to be desired because PHP core developers do not have the habit of using source code auditing tools to prevent security bugs. The matter of the PHP source code quality and security bug prevention was one of the main topics discussed by Manuel Lemos and Ernani Joppert in episode 21 of the Lately in PHP podcast.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly. You can also subscribe to their feed to get this episode automatically (and past/future ones too).