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.

In a new post Andrew Podner recommends that, as you're doing your day to day development, you try your hardest to create testable code, no matter how painful it is.

I look at the situation we have gotten into by having this problem [of replacing a large legacy application], and frankly, it is like the tech version of 'Scared Straight'. The paranoia of such a far reaching application within the enterprise that absolutely has to deploy successfully and also be very flexible to meet the needs of the future have driven me to the point of near madness in trying to make sure this thing is bulletproof, enter Test Driven Development.

He includes an example situation he recently was faced with in his code...and opted for the "easy" way out (difficult to test). He talks some about the issues, dependencies and coupled code this has created. He does, however, show a solution to the issue - passing in the dependencies as they're needed, not defining them in the method.

For me, writing custom apps in an enterprise environment is not about rapid deployment and looking like a hero. It is about deploying software with a design life of 7-10 years, because the change management involved in deployment is not something you want be be doing over and over again. Testable code with 100% coverage of unit tests, well developed integration testing, and prolific use of tools like PHPUnit & Selenium are part of the development culture because while speed is important, durability is even more critical to business.

In a new post to his site Justin Carmony shares some of his experiences with doing test-driven development (TDD) for a new project he was working on interfacing with the Omniture API. In it he shares six lessons he learned during the work.

At work we use Omniture for our web analytics, and for a long time I've wanted query our Omniture Data to run some internal reports. I discovered that Omniture has a restful reporting api, and after using it for a little bit I decided it would be nice to write a wrapper library for it. Since I had recently taken the PHP Testing Bootcamp from Chris Hartjes, I decided I wanted write it using Test Driven Development and really get my feet wet. I also decided I wanted to make the library compatible with Composer. After the weekend was over, I had an almost finished library that just requires some more work to be done, but I learned a great deal that I thought I'd share.

He's broken the post up into sections, each with their own summary:

• TDD is 90% changing the way to write code, and 10% writing tests
• Understanding Mock Objects is the real key.
• It takes almost twice as long to write code and tests then just code
• Its extremely easy to get out of the habit of writing tests.
• You'll refactor quicker and more often when writing tests
• Having testable code made me feel much better about sharing the code.

Scott Mattocks has wrapped up his series about LUCID development with the final letter of the acronym - D is for Documentation.

Despite mankind's best efforts, writing code is still clearly an exercise for talking to computers. It has not evolved to the point where talking to a computer is as easy and natural as talking to other people. That's why documentation is so important. Programming languages are just a translation of a developer's intent into something a computer can execute.

He points out that even a little documentation can go a long way (even in presentations with code in the slides). It provides context and the intent of the code, not just details about what it's doing. He proposes a compliment practice to test-driven development (TDD) that turns the documentation process around - Documentation Driven Development. This is essentially writing up what the code does first, then writing tests to check it and only then writing the code to make it happen.

If you're interested in the rest of the articles in the series, check out the LUCID article on his site with links to each letter's article.

On NetTuts.com there's a new screencast posted showing you a good way to create a better workflow in your PHP development using Composer and PHPUnit.

In this video tutorial, we'll again focus on workflow. Specifically, we'll use Composer's built-in autoloading capabilities, along with namespacing, to make for an elegant testing experience. We'll also review a handful of PHPUnit best practices, as we get setup with these tools.

He shows you how to use Composer to load in the packages from other projects (as well as your own) and using PHPUnit to execute unit tests for your application. He uses test-driven development, but it's not a required part of the workflow. He helps you create a simple "Calculator" test. He also shows how to manually modify the Composer classmap to load in your own classes.

On NetTuts.com today there's a new article that suggests that 2013 is the "Year of PHP" and how recent additions to the language are going to effect its future.

2012 was an excellent year for the PHP community, thanks to many badly needed features being added to version 5.4, as well as the countless projects, advancing PHP to the next level. In this article, I'd like to review a handful of the issues that people had with PHP in the past, and provide a glimpse at why 2013 just may be the year of PHP!

They talk about some of the hostility (stigma) that's always been present when people talk about using PHP and a reminder that PHP, as good as it is, isn't perfect either. They talk some about the current state of the language and community and about how tools like Composer and methods like test-driven development (as well as major features being added to the language) have it poised for even more growth in the next year.

In an effort to spread the good practices that TDD (test-driven development) can bring to your development, John Cleary has proposed what he's calling this "12 TDDs of Christmas" for the end of the year. The goal is to get you doing TDD, one piece at a time, and seeing the benefits.

So here is the challenge. Starting Wednesday 26th Dec and for the following 12 days I'm going to do just one kata per day. I'm calling it the 12 TDDs of Christmas and it would be pretty cool if a few other people out there took up the challenge with me 0 fancy it?

The 12 days started on December 26th, so there's a little catch up work to do, but you're not too far behind. The "katas" are short problems to solve that only require a bit of code to get working. The idea, though, is that you practice with the test-first methods and use these examples as the assertions.

Matt Frost has a new post today helping to explain test-driven development (TDD) for the unconverted and some of the things that come with it in practice.

You've heard of Test Driven Development, but you think; "I've got a horrifying monstrosity for a codebase, it's not testable so I can't do TDD". Let me be the first to tell you that you're wrong. I'm not into writing really controversial pieces, castigating people for not doing things a certain way. If you've considered TDD at any point in time, it's because you understand (at least in the theoretical sense) that having predictable software is beneficial. So this is for you, unconverted developer...

He talks about how using TDD can help you build confidence in your code, make debugging issues easier in the project simpler and how - despite the initial time it takes to implement it in the process - it's worth it in the end. He also includes a few helpful suggestions when your team doesn't want to follow the method.

Shashikant Jagtap has Behat TDD testing tool and the BrowserMob-Proxy to make an automated system that collects performance data on your applications (including load time, recording headers and simulations of network traffic and latency).

BrowserMob Proxy is a utility which is used for capuring HTTP traffic and performance data from the browser. BrowserMob-Proxy adds in essential missing capabilities such as checking HTTP status codes and injecting headers for HTTP Basic Auth. Web Perfomance data can be manually captured by other tools like Firebug or Developers Tools. Using BrowserMob Proxy we can capture perfonace data in HAR format while running automated tests.

He includes the commands you'll need to set up the PHP interface for BrowserMob (PHPBrowserMob) the proxy itself and a sample test and context file that runs some checks against Facebook.

Chris Hartjes, a big proponent of testing in web applications (mostly in the PHP realm so far) has a new post to his site with some of his thoughts about PHPSpec, the specification-driven testing tool recently released by the same folks who made Behat.

I think that we are witnessing the first wave of new testing tools in the PHP community that allow developers to wrap their applications in automated tests. I am familiar with the BDD-style that is being promoted in PHPSpec, through my work with Behat to create automated user acceptance tests. I think if you want a tl;dr version of PHPSpec I would tell you "write hybrid unit/integration tests using plain language".

He notes that writing code to match a specification has similar concepts to using unit testing for TDD (with something like PHPUnit). He points out a few interesting things like the use of mock objects and the fact that you'll still need to write some code to make tests work - that's unavoidable right now.