Scaffolding wpunit tests

Giving a name and code to an undefined entity.

Strict definitions

In TDD terms a “unit” test is a test that exercises a discrete and atomic software component.
In PHP terms this might mean a function or a class and its methods.
Above that there is “functional” testing that’s meant to exercise the combination of those small units of software.
So if I have class A that picks a random string in an array, class B that generates a male or female title, class C that assembles those to generate random salutations I could have a unit tests for each class and a functional test to make sure that those 3 classes working together will work as expected.
Think of a chain (functional) that’s made of interconnected rings (units) that’s just a part of a bigger machine (acceptance).
So where does test that’s meant to test a single class that but depends on WordPress defined method falls?
Right between functional and unit testing I’d say.
It’s not testing a chain of elements but it also requires quite a set up (a WordPress instance) to run.

Wide scopes

With the above distinction in mind I’ve updated the wp-browser suite to scaffold, along with the Unit, Functional and Acceptance suites, the Wpunit suite.
That’s going to use, by default, the WPLoader module alone and the idea is to have “something like” the Codeception Laravel module or the Symfony one.
A case for such a suite would be one where I need to test a class like this one

class MyWidget extends WP_Widget {
    // ...
}

Decoupling WordPress classes and functions is an hard work and spinning up a whole WordPress instance in the same scope where the test are running is simply easier in their current state.