With the new position comes more of the stuff I am really passionate about: testing and automation. Which also got me to thinking about the reasons why I am so passionate about these things. I thought I would create my own little testing mini-manifesto here. The ideas my podcasting partner did with his MicroPHP Manifesto made me realize that sometimes it is good to write these things down, as it were.

His manifesto incudes a set of basic (yet fundamental) ideas about application testing:

• I test because the tools are easy to use
• I test because I don't like surprises
• I test because I want people to understand what I've done
• I test because I want to be able to change things fearlessly
• I test because automation is a secret weapon
• I test because it forces me to focus on design
• I test because to me it is the right thing to do

Our own Elizabeth Naramore interviews Ed Finkler, author of the MicroPHP Manifesto.

• The MicroPHP Manifesto
• What was the inspiration for it?
• Let's talk about the controversy around it - where do you think that came from?
• What do you think the impact of the Manifesto has made on the community? Do you think it's given cause to people to rethink their own assumptions?

To listen you can either download the episode (mp3 or ogg) or subscribe to their feed via RSS or iTunes.

My previous post, The MicroPHP Manifesto, resulted in much excitement. In between fits of rage and crying, I found some time to answer folks questions, and also discuss the topic on the /dev/hell podcast with my cohost Chris Hartjes. To summarize and address some of the common questions, I felt I should write a small FAQ.

Questions asked so far include:

• So you think full-stack frameworks suck?
• You need a large framework to enforce best practices!
• You should check out my microframework!
• How do you choose what gets listed in the MicroPHP code collection?
• Why do you hate Rush?

If you have a question you don't see listed, drop him a note and he'll add to the post with more answers.

Earlier in January Ed Finkler announced the MicroPHP manifesto. It seems to be a rant about against the practices of developers that make PHP development more complicated than it should be. This is one of the main topics discussed by Manuel Lemos and Ernani Joppert in the episode 20 of the Lately in PHP podcast. They also discuss the final release of PHP 5.4.0 and whether you should upgrade it or not, the repercussion of the PHP Hash Collision Vulnerability, as well the trends of PHP world based on the analysis of the PHP Zeitgeist 2011 initiative.

You can listen to this latest episode either by using the in-page player or by downloading the mp3.

Ed's recent blog post labeled the The MicroPHP Manifesto got a lot of attention. [...] In general I totally agree with Ed on the point that we need more decoupled components in the PHP world. The timing seems a bit odd since exactly that seems to be an emerging trend with all the various libraries cropping up since PHP 5.3.

He gets into more of his thoughts comparing the recently popular microframeworks to the full stack, broad use case frameworks that try to provide everything you might need. He talks about the difference between them related to configuration over code and when he sees is a good shifting point to move from the simpler micro world to the full stack (hint: business logic).

So the key take a way point is that when choosing to go micro or full stack its very important to consider in what kind of company on what kind of products you are working on.

I came across a rather interesting post yesterday entitled The MicroPHP Manifesto. The author made clever use of a very interesting analogy (drum players) to try to prove his point that less is more. The article makes a very interesting read, and I would suggest that everyone reads it. Go ahead. I'll wait. With that said, I have to disagree with the article rather vehemently. I think the message is somewhat right, but for all the wrong reasons.

One of his main points is that he believes in the "right tool for the right job" mentality and suggests that, like the manifesto says, small things are good for some jobs. In other places, though, a full-stack framework (or component-based one) is the right fit. He finishes off the post by going through the manifesto points themselves and adding commentary with his thoughts on each.

As of the time of this post there's about sixty-five comments posted to the thread with widely ranging opinions:

• "How is [lots of separate libraries scattered around] better than simply using a framework?"
• "This is part of the reason for the PSR0 reference for auto loaders [...] Part of the problem is an inconsistent way to load modules."
• "I would love to see this become a trend in the PHP community. I think this is exactly the direction needed to make PHP exciting again and regain mindshare in the wider dev community."
• "I know, many people are currently on that micro trip but seriously, I think that there is as much to microframeworks as there is to microoptimization"
• "A framework is a tool. If you don't need it, why use it?"
• "There's a tool for ever job, I agree some projects or companies "need" something like Zend or Symfony for their enterprise projects. Whether or not you'd want to work on a project with 1000's of classes is something else all together."

Read the full responses to Ed's article here.

The approach I've been taking lately is to start with as lightweight a foundation as possible, in the form of a "microframework." [...] For additional functionality, I pull in lightweight libraries that help me accomplish only the tasks I need. Clarity and brevity are my top considerations. My other big consideration is the commitment I make when I use code I didn't write.

He goes on to talk about difficulties finding lightweight libraries to suit his needs and gives some cloc benchmarks for the Symfony HttpKernel and the Slim and Epiphany microframeworks. The end of the post is the most important part - the manifesto itself...one he hopes will ring true with the development community. It includes things like:

• "I am a PHP developer. I am not a Zend Framework or Symfony or CakePHP developer."
• "I like building small things with simple purposes."
• "I need to justify every piece of code I add to a project."
• "I want to write code that's easily understood."

For more read the full post over on his blog.

A DI framework is predominantly interested in the creating and plumbing together of objects. The work of creating and plumbing together objects is mostly very simple, as such do don't need a framework to do any of it. [...] In the end, the reasoning for using a DI framework should be the same reasoning for use of any library or framework.

He breaks it down into a series of reasons why it would be beneficial to the general PHP development community:

• Increased usability
• Easier to maintain
• Makes for simpler unit testing
• Less invasive code
• Removing the need for boilerplate code

There's lots more good stuff in there than this, so be sure to check out the rest of the post for more of his thoughts.

This article is part of a series where I will go into great detail about Dependency Injection (DI) and how it applies to PHP. I will layout exactly how I think DI should be used in PHP with the creation of a new code project as the result.

He has made a list of things that he's want a DI framework to do for him including:

• functionality that helps to keep things manageable
• making it all testable
• make a reduction in the need for "boilerplate code"
• work completely standalone if need be