I wrote and maintain the theme for
my wife’s website. When working on it in the
past I’ve been under time pressure because the Craft
Fair was close, so I haven’t kept the code to my
usual standards. Over the past year I’ve been improving my processes, e.g.
Populating dev website from production
website, and more
recently I’ve been improving the code by breaking the monolithic
into separate files
and writing tests.
functions.php still exists, but it’s now 149 lines
rather than 1227 lines
For testing I’m using PHPUnit with
I’ve been able to achieve 100% test coverage (excluding
functions.php which is
now mostly configuration rather than code), and along the way I’ve improved and
cleaned up the code significantly. The other PHP files in the theme are used
automatically by Wordpress to display content of different types and have very
little logic in them, so I don’t feel they are worth testing and testing would
require faking lots of Wordpress functions. I created a phpunit.xml config
phpunit --generate-configuration plus editing so that I don’t have to keep
supplying command line flags. I wrote some test helpers and fakes (e.g.
I put them in
src/ rather than
test/ so code coverage would be measured for
them - this gives me an easy way to spot unused code in test helpers that I can
functions.php into separate files has had multiple benefits:
- It’s much easier to understand a piece of functionality because all the related code is in an individual file rather than jumbled up with lots of other code.
- Writing tests was much more satisfactory because I had intermediate targets
to hit 100% coverage on rather than a single gigantic file where progress
would be glacially slow. I wouldn’t ever get to 100% coverage on
functions.phpanyway because too much of it is Wordpress configuration that can’t be meaningfully tested in isolation.
- I improved the code as I wrote the tests by removing unnecessary code, making cleaner interfaces, and breaking spaghetti code down into separate functions. This was all easier when working on small piece of functionality than it would have been working on everything at once. The code grew in size by approximately 200 lines or a factor of 1.158.
I tried PHPLint because I’m a big fan of linters and style guides, but ironically it crashes on startup with an exception :( It appears to have broken with PHP 7.3 maybe?
I used PHP Coding Standards Fixer to automatically
fix some things that a linter would complain about. When I enabled the large
sets of rules like
@PhpCsFixer I was unhappy with the output, e.g. multi-line
arrays and function calls had their indentation removed, which I strongly
dislike. I read through the docs and picked
out the rules I agreed with, put them in a .php_cs.dist config
enabled them one at a time to make small related changes I could easily review
rather than one giant commit. Having tests made me confident that the tool
hadn’t broken my code with the changes - yay for the tests! I’ll probably test
out more of the rules in future, but an evening’s work has already gotten me
good benefits so I’m happy with the investment of time. There are many
different style guides for PHP that seldom agree, so this is an area for future
I installed everything I needed on my laptop with these commands:
brew install phplint phpunit php-cs-fixer # Earlier versions won't build with PHP 7.3 pecl install xdebug-2.7.0beta1