Whenever I try to explain unit testing to another developer, I refer to the “smallest unit of work” that’s possible to test. Often this leads to head-scratching and confused looks, so let me explain.
Octave
My wife is taking a Coursera class on machine learning. Her instructor has put together a fantastic set of exercises in Octave to teach the material. He walks through the material one step at a time, and presents functions with incomplete bodies – the assignments are to fill out the body of each function with equations covered in the lectures.
Once the function is complete, you can run the exercise’s main script, and it will step through each part of that week’s exercise, executing your code as you go. When you’re right, everything runs and gives you the data you’d expected it to.
When you’re wrong, you’ll see a flood of error messages or incorrect data. Unfortunately, this indication of being wrong usually comes halfway through what’s often a very long program.
So a few students and TAs got together and publish weekly unit tests for the course.
The unit tests are simple function calls that populate the environment with known data, execute just the function you’re working with, and return a small subset of data you can compare against a set of expected solutions posted in the class forum. Running these tests allow students to debug just the exercise they’re working with, without needing to run the entire course program.
WordPress
I don’t work with Octave on a daily basis.[ref]I’m glad for this. As cool as the language is for mathematical stuff, the available IDEs are clunky and buggy, and I don’t understand much of the syntax in the first place.[/ref] I do, however, work with WordPress – unfortunately WordPress’ test suite fails to test only the smallest unit of work.
This has been my ongoing gripe with the WordPress unit test suite. Yes, it lets us find bugs in our code and prevent regressions. Yes, every patch submitted nowadays should have some sort of automated testing performed to make sure it doesn’t introduce yet more bugs.
But the WordPress unit test suite requires a database first of all, which means it’s not isolating the code you’re trying to test (i.e. a single function) from the rest of the code base and its dependencies. Also, I’m often criticized for setting up an initial environment when building a test (again, I do so to test just the function in question rather than the set of APIs upon which it depends).
When you test the smallest unit of work – just one function – you should only need that unit of work available to the test code. No database. No other application APIs. No global state set up by other in-application functionality.
This is one of the primary reasons I’ve helped build WP_Mock. WP_Mock allows you, within a WordPress theme or plugin, to test just the code in question by mocking the WordPress API. In most of my test scenarios, the WordPress codebase (and the database against which it runs) is not even included.
My tests use WP_Mock to set up an initial environment, they then run just the function I want to test (against that known/static environment) and assert the environment meets certain expectations after the function completes. WP_Mock allows me to mock the behavior of both WordPress APIs and internal theme/plugin APIs – this allows me to isolate functions within my application from one another so I can truly test one unit of work at a time.
How isolated is the code you work with? When you write tests, are you really testing the smallest unit of work possible?
