Posted on

PHPUnit and Debugging

Lately I’ve been using this simple setup to print stuff to the terminal during PHPUnit runs.

    /**
     * @var bool
     */
    public $debug_on = false;

    /**
     * @param mixed $something
     */
    public
    function debug_print( $something ) {
        if ( ! $this->debug_on ) {
            return;
        }
        fwrite( STDERR, "n" . print_r( $something, true ) . "n" );
    }

Use Case 1

Control debug printing by means of opening and closing “parentheses”:

$tested->debug_on = true;
//...
$tested->debug_print( $stuff );
//...
$tested->debug_on = false;

Notice that you can also control (everything or something) either from the testing or the tested code, the only difference being the use of ´$this´ instead of ´$tested´.

Use Case 2

Control debug printing by means of an automatic toggle like this one:

static $count = 0;
$this->debug_on = !$count++;
//...
$this->debug_print( $stuff );

Same considerations as above.

Posted on

Backup of a WordPress plugin / theme directory.

I often think: I’m just gonna do this little thing before and then I continue doing that.

The last little thing spanned a couple of days. I needed to make a patch for WordPress and cross fingers after pleading to apply it.

I could be wrong, but some years ago it was considered best practice to have users of your plugin to store their customizations into the same plugin directory. Well, maybe nobody advised me to but nobody advised me against either. The point is that it looks really neat to make users store all the stuff related to your plugin in the same place where your plugin leaves.

Years ago, however, there was no problem. Whenever you wanted to install a new plugin or update an old one, you always needed to first download it to your PC and then to upload it to your remote site, into the ´/wp-content/´ directory, possibly by means of an FTP client. The process was repetitive and cumbersome, but exactly by virtue of that you did things orderly.

Always make a backup of the stuff you are going to replace.

That was the mantra. Even on toilet walls you could read it.

Then, the update now link appeared and it all changed, for better. No more nothing, just a simple click and … magically everything happened remotely. Really really good feature. But there was a problem. A no-feature became a feature (bug?). The magic update now functionality never makes a backup of what is gonna replace. Why? I really don’t know. It is still a mantra for me!

So, the last couple of days, I made a patch for WordPress 4.1 and submitted it minutes ago. It’s quite simple: Always make a backup of the stuff you are going to replace. Then a plugin / theme developer can access a backup of their previous stuff and transparently migrate the previous custom files to the new version. For example, from an activation hooked function:

{[ .example | 1.hilite(=php=) ]}

Posted on

Disable Xdebug for PHPUnit

If you do not need Xdebug when running tests with PHPUnit, then you can disable it and run your tests much faster. However, it’s not easy for me to remember to disable Xdebug, so in my TestCase class I’ve overridden ´setUpBeforeClass´ and ´tearDownAfterClass´ like this:

{[ .xdebug | 1.hilite(=php=) ]}

That only toggles the backtrace, so the speed gain is less impressive, but for me is an acceptable trade-off.