In a new post to his site Frederick Vanbrabant tackles the integration operation segregation principle. While the term sounds intimidating, it's just a long way to say something you probably already do: refactor code into smaller testable chunks.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and me were discussing some code that we refactored earlier . Not so long in the conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim.

Now I’m going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

He starts with some simple code for a "calculator" class with a calculate method to handle the pricing of a rental car. He includes the test for the class/method as well, using a mock object and several expects calls to handle the method calls. The test ends up being larger than is probably good, so he looks into refactoring the original code to abstract out some of the functionality and make it more testable. In the process this also makes the code easier to follow and, while there is more of it, more maintainable and flexible in the end.

NetTuts.com has a new tutorial posted suggesting a few ways you can make testable and maintainable code in PHP applications.

Frameworks provide a tool for rapid application development, but often accrue technical debt as rapidly as they allow you to create functionality. Technical debt is created when maintainability isn't a purposeful focus of the developer. Future changes and debugging become costly, due to a lack of unit testing and structure. Here's how to begin structuring your code to achieve testability and maintainability - and save you time.

There's a few concepts they cover in the tutorial including DRY (don't repeat yourself), working with dependency injection and actually writing the tests with PHPUnit. They start with a bit of code that needs some work and use the tests to help refactor it into something that can be easily mocked (using Mockery).

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.

Chris Hartjes has written up a new post for his site, So you want to write tests, giving a good overview of some of the things you'll need to consider when wanting to move into a more test-friendly development world.

I often get asked for some advice on how to get started with writing tests for your PHP code. It’s a fair question, since I am presenting myself as an expert-ninja-rockstar-sensei-opinionated-egomaniac on the topic. I often struggle with coming up with an answer that can fit into the 140 characters available via Twitter, but clearly this is not a good strategy. As an early Christmas 2012 present to all my loyal followers, who put up with my never-ending stream of nonsense and provide a slowly-increasing portion of my income, here are my thoughts on how to get started with testing your PHP code.

He offers a list of suggestions, each with a bit of explanation:

• Learn how to recognize untestable code
• Keep learning the language
• Chain units of code together for greatness
• Start asking "how am I going to test this?"
• Stop people from pushing code without proof it's fixed
• Stop people from doing things manually
• Stop using tools without test suites
• Always wonder if you're doing it right

Chris Hartjes (aka "The Grumpy Programmer") has made a name for himself in the PHP community as a big proponent of testing of all sorts in web applications. He's taking things to the next level with his own "Grumpy Learning" grouping.

As I also create more products I need a place for them all to live. I have books, and now a course I can teach and I am planning on producing screencasts for sale as well. With that in mind, I am happy to announce I have created Grumpy Learning, an umbrella site for all my training and teaching efforts to hang from.

His first book covered writing testable application, his second book looks more specifically at using PHPUnit. His latest offering is a PHP Testing Bootcamp - a three-session guided look at some of the concepts he shares not only in his books but also from his own experience (January 3rd, 10th & 17th).

On his blog Brandon Savage has a new post reviewing a book from Chris Hartjes, “The Grumpy Programmer’s Guide To Building Testable Applications”.

When most developers think about books on testing, they think about books that highlight things like “test driven development” or “how to build a test for X.” [...] This is not true of Chris Hartjes’ book, “The Grumpy Programmer’s Guide To Building Testable PHP Applications”. When I asked Chris if I could review his book, I expected a step-by-step guide to writing tests. What I got was a step-by-step guide to building an application that COULD be tested. There’s a big difference, and it’s important to understand the distinction.

He points out that the book provides more about good application structure than who to write the tests for it. It provides a guide to creating modular applications that can be easily pulled apart and tested as well as some practical examples. He also includes a few "wise words" quoted from the book including: "if it’s not yours, wrap it up" and "testing is good; testable applications are better."

You can pick up your own copy of the book fron its page on the Leanpub site.

As Tobias Schlitt points out in this recent post to the Qafoo blog, the recording of a webinar he did (for Zend) about "Writing Testable Code" has been posted for listening online.

In this session you will gain insight into the secret of writing easily testable code and you'll learn how this relates essentially to good object orientation.

The recording is just one of many webinars Zend offers on a wide range of development topics, including:

• Design Patterns in PHP
• Multibyte string handling in PHP with the mbstring extension
• Strong Cryptography in PHP
• Using Jenkins/Hudson for Continuous Builds

Almost all presentations also come with PDF versions of their slides attached, too.

Volker Dusch has a new post reminding us about what the "unit" part of "unit testing" means - small chunks of testable parts in an application.

What does the word UNIT in unit testing stand for? Think of an answer and read on! So? Did you say “A method! Because we test methods!”? If so let me offer another perspective.

He suggests that, rather than about just the methods in the class, it's more about testing the "observable behaviors" of the class. That is, anything that you could publicly use the class for and have something happen. He gives examples of this shift in focus - calling setValue and evaluating the result versus just calling the class property itself (then calling the method). He also includes a bit about testing behaviors - what happens when my script does [this] and how does that effect the overall class.

When your tests fail but the class “still works” and you need to “fix the tests” the your tests are worth a lot less as they don’t really give you that cozy safety net that they should provide you with.

In this slightly older (Nov 2008) but useful post to Misko's blog, he takes a look at a few common flaws that you should avoid in writing up your code (in any language really).

To keep our code at Google in the best possible shape we provided our software engineers with these constant reminders. Now, we are happy to share them with the world.

Here's the list of the flaws:

• Flaw #1: Constructor does Real Work
• Flaw #2: Digging into Collaborators
• Flaw #3: Brittle Global State & Singletons
• Flaw #4: Class Does Too Much

Each includes some warning signs to keep an eye out for to see if you and your code might be straying the wrong way.