Unit Tests Work! A Look at WordPress

Posted by santosj on August 25, 2008

Unit Testing works! The best part? It is fun. At least at the expense of someone else. I pick on WordPress because it is the system that I’m building unit tests for. I’m going to look at different bugs that were solved and may have been found because of unit testing.

add_filter() in plugins.php

Was Reported. Tested and solved by unit testing.

Problem

Usage with objects is broken, even with the current version (2.2.2) and trunk. The problem is from using serialize on classes, which when added, after the properties change, cannot be removed. This is because the class “state” has changed and will serialize to a different string than what was added.

Solutions

  1. The fix, that won’t affect all plugins that use classes, is to explicitly check for objects and add a new property to that class that can be later referenced. It works, but it is slow, almost 3x as slow as serialize. Wasn’t tested on PHP 4 systems, but in theory, if it works on PHP 5, it should work for PHP 4.
  2. All plugin authors, which choose to use classes to include __sleep() method in their class, which cache the state at the beginning and return that state. This would provide consistency, but would require work for all plugin authors and would force WordPress blog administrators to upgrade their plugins.
  3. Don’t use classes as plugins or use another class for storing properties.

apply_filters() in plugins.php

Was patched and was only confirmed by unit tests.

Problem

If you remove a filter that is part of the same tag inside the apply_filter loop, it will ignore the rest of the hooks. (from ticket).

Interestly, the problem was in there places, but only fixed in two. Also interesting is that the functionality was duplicated in three different places instead of creating a function and using that instead.

Solution

See ticket.

merge_filters() in plugins.php

Was reported.

Problem

Array_merge will append (the desired result) $wp_filter['all'] to $wp_filter[$tag] and completely destroy the priority that was set for $wp_filter[$tag] (most likely not the desired result).

From this I can gather that a person won’t be able to remove a hook that was added. I can also figure that nothing and no one uses $wp_filter['all'] because it would destroy the priority for every hook. Or it works and I’m crazy.

My tests prove that 1) array_merge destroys the priority, and 2) if I had tested for it, it would have proven that you wouldn’t be able to remove a previous hook afterwards (conjecture, will need to add it into the test).

Thanks to Sam Angove, from wp-hackers, there are several bugs in the formatting.php file, so at least it proves that Unit Testing is justified. If it is justified with only two Unit tests with over 50%, I think it also says a lot for other projects.

Unit Testing is awesome, PHPUnit and SimpleTest is awesome. What else more do you need?

Possibly Related Posts:


Web Applications,

Comments are closed.