In this new post on DZone.com, Giorgio Sironi suggests that "all debugging and no testing" in your development practices can be more difficult in the long run.

By now you have already understood that I would always proposed automated end-to-end and unit tests as a way to substitute much of debugging. End-to-end tests can serve only to discover that a bug exists, while a unit test's job is instead to tell you exactly where the problem is.

He advocates testing because it fits two needs - it's repeatable (a consistent, "third party" structure) and it allows you to find the pieces of code causing the issue more quickly rather than having to guess where the problem is an insert checks. He doesn't suggest completely getting rid of things like Xdebug, though. They have their place and he even suggests some configuration changes that can help make it even more effective.

Phil Sturgeon has a quick new post with a code snippet that could make your debugging life a bit simpler - a "dump" function that can give you a bit more information about your error than a standard var_dump.

When trying to work out what the hell is going wrong in your PHP application the first thing most of us start doing is madly start var_dump()'ing everything possible to work out where the problem is. var_dump() is fine, but by default it comes out in one line. So then we need to echo <pre> tags. Then we can't always see whats going on, especially if the background is black and bla bla bla so it goes on.

He mentions an alternative like XDebug, but that also requires access to install it on the server. His alternative, the "dump" function, catches the error, pulls out a backtrace of the path your script took to get there and echoes it out with the line number of the error and filename.

Matthew Turland came across an interesting bug when working with the Cares Document Checker he's developing related to linting (running a syntax check) on a given PHP file.

While doing a lint check on a code block, a parse error was occurring on a line that contained a comment in the original source file. [...] Presumably what was happening was, even though the var_dump() call showed that actual newlines were being interpreted correctly, the r was also being interpreted rather than taken literally. This caused the comma following it to generate the error I was receiving.

An alternative to the method he was using, shell_exec, is proc_open, a function that opens a resource to handle a command execution and allows for more than just the "point and shoot" execution that things like shell_exec, or system.

DevShed has posted the next part in their series looking at using the XDebug extension. This time they focus on the var_dump function and the enhancements the extension brings to the table.

As you may know, "var_dump()" is a PHP native function, but the X-debug library provides an enhanced version of it that's capable of retrieving much more information about a supplied variable. These capabilities greatly extend its usefulness in debugging.

This enhanced version of var_dump displays not only the usual variable information (types, value, etc) but also allows for more advanced output like the object definition, including properties, in their example.

Brandon Savage has the first part of a series posted (with N parts) showing off some of the tools that PHP already has built in to make your debugging life easier.

PHP has a large number of tools for fixing bugs and resolving underlying issues. But many people don't know what they are, and some of them are extensions requiring installation in order to work. In this series, we'll explore some features for debugging PHP scripts, from the most basic to more advanced.

He looks at three of the most basic ones (and ones that most developers I know out there use every day) - var_dump, print_r and var_export. Examples of each in use are included...

Vinu Thomas has proposed a replacement for the usual var_dump or print_r sort of debugging developers tend to do - Krumo.

To put it simply, Krumo is a replacement for print_r() and var_dump(). By definition Krumo is a debugging tool (now for PHP5 only), which displays structured information about any PHP variable [...] it does the same job, but it presents the information beautified using CSS and DHTML.

It also supports output of other data in a "pretty format" like backtraces, included files and a listing of all constants. You can check out a demo of it in action here.

On the Zend Developer Zone today, Stefan Priebsch has written up an article introducing fellow developers to XDebug, a popular PHP debugging suite.

This article is the first installment of a five-part series of articles covering xdebug, a free and open source swiss army knife tool for PHP developers. xdebug is a PHP extension created by Derick Rethans, one of the PHP core developers. This week, we will show you how to install xdebug and introduce you to some of the basic features. In the subsequent parts of this article series, we will have a closer look at one of xdebug's main features, namely tracing, profiling, debugging, and code coverage.

In this first installment, he looks at installing the software (both on a unix-based system and on a Windows box) and how to turn it on to work with your web server. He also mentions some of the error output options including the "new and improved" var_dump call and the stack trace method to help you locate exactly where in the code the error's hidden.

Sara Golemon, being interested in Unicode as she is, decided to investigate further when she saw a recent post about issues with Unicode math symbols:

Being a whimsical sort, I decided that actually implementing his request would be more fun than simply pish-poshing it. I'm not suggesting this be part of PHP6 (I still don't personally think it's a good idea), but it's a fun exercise and good for a conversation starter...

There's several things she can now do with the special characters including dumping out the results of divisions, comparisons and fractions natively.

In a new post today, Clay Loveless talks about some issues he's been having with PHP and JSON, specifically with the JSON encoding method in PHP 5.2.1.

As of PHP 5.2.1, json_decode() no longer follows the published standards for JSON-encoded texts. Why not? For no reason other than the convenience of those ignorant of JSON standards.

His complaint stems from the results of a vat_dump statement - prior to this version it would give a NULL, but now it returns a "bool(true)" value back, resulting in some breakage of previous scripts. He spends the rest of the post explaining his voyage through the JSON world and how things are supposed to behave. He also digs a little deeper into the var_dump issue and why he thinks it's such a bad thing.