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:

• WordPress Plugin and Theme Scope
• What I’ve Learned From WordPress
• Why Do I Feel Like an Asshole When Criticizing WordPress?
• PHP5 Straw Man Argument
• WordPress 2.7 Changes Class for Plugins

The content in Joshua Eichorn post about certification and test automation has been on my mind with the development of WordPress and others. Padraic Brady has been discussing Unit Testing and test automation for a while now. With good reason, it should be part of every project.

I had to learn the hard way, but once you get into the swing of writing tests, it slowly starts to make sense. It makes a lot of sense. Something that bothered me about WordPress were regressions. WTF? Well, if there were unit tests and acceptance tests, the probability of that happening would decrease tremendously. Depending on the quality of the tests of course.

The good news is that WordPress is growing up also and has initial development of functional test automation. Shouldn’t every open source PHP project take the step forward in maturity and include the step of writing tests? Cheers for those projects that already have done this.

However, this isn’t the fault of the core developers of these projects. Writing tests may be boring and fun (I would be interested to find out why this is), but the core developers want to use their time to develop awesome and probably slightly broken features. If that is the case and users care, then I think it would be useful to write the tests instead of complaining. If not, then all is well, because users will eventually discover the bug after accessing the branches of code from a much higher level.

Cheers to any project that actually reads this post and follows through, if not already doing so. Although that outcome will most likely be coincidental, in any case. It is unlikely any project would change without user involvement.

Possibly Related Posts:

• Bullet: E-Book Library Management and Content Server
• Using ZendFramework 2 beta1 For Directory Project
• The Way of Kings and Cosmere Theory
• “In Time” Movie Premise Flawed
• Completing HTTP Library For PHP

I think for as much coverage as possible the following should be done for encompassing the whole of WordPress using tests. The PHPUnit version 3.2.0 should include many new features that should allow for better testing WordPress in environments more true to XP programming techniques. Along with PHPUnit, I have been meaning to build a site for statistics, but I think it will come later when I have more tests done.

1. Unit Tests and Characterization Tests.
2. Hook Tests
3. Database Tests
4. Acceptance Tests

Unit Tests and Characterization Tests

There aren’t very many functions or library files that allow for true Unit Testing, so I would rather combine the two tests, instead of trying to keep them separate. This would allow for coders writing tests to not worry about whether the function can be unit tested or have characterization tests. Comments should be made for the methods on what is tested to let others know if the test is an unit test or characterization test to the knowledge of the author.

All actions and filters will have to be disabled while running the tests to allow for just testing the functions. Testing the hooks would be done separately. Looking through some of the bug reports, it seems that some hooks are required to test for some obscure bugs. This should be done in the next section.

The unit tests and characterizations tests should be run by themselves, separate in execution from the rest of the tests. I have also been meaning to remove dependencies on my changes. I think that since the last WordPress commit, that is no longer an issue.

Hook Tests

Remove all filters and actions and manually add the hook workflow to test the result. This would require mock functions that duplicate the functions or running the full version of WordPress, except for the output.

Testing the hooks has more to do with regressions and refactoring of hooks, since hooks should work as long as the plugin test passes.

Database Tests

PHPUnit 3.2.0 will include DBUnit which will allow using a snapshot of the database and test output using that instead of a real database. This should be extremely helpful in testing Database Queries.

Acceptance Tests

Test the blog site to make sure that everything appears correctly.

Possibly Related Posts:

• Calibre Improvements
• DragonU Bug Tracker Dev – Milestone 1
• Dragon MVC
• Why I Contributed to WordPress
• DragonU DB Component