Developer errors, tester errors and Codeception modules

I’ve been using my WordPress Browser module to write tests all day, enjoyed it and would like to make a note to self about writing modules: there are developer errors and there are tester errors.
One is good and one is bad.
In a test-driven development process I get to wear both hats on and off for seconds at time but still that’s an important distinction that’s made where a problem can be solved: if it’s solved in the subject under test then that’s a developer error while it will be a tester error if it’s going to be solved in the test code; I could go as far to say that developer errors are what TDD looks and craves for while tester errors are a waste of time.

So take care of the tester

With such a motto I’ve built the module to allow for a configuration setting, checkExistence, to be set to true or false to make the module take care of the tester, to a point, while writing tests. I thought I would not have used it much but ended up turning it on.
I’ve gone over it in practical terms in an earlier post but appreciated the value of the possibility while using the module consistently.
A line of test code like

$I->havePostWithTermInDatabase(115, 23);

is used to delegate all the menial job of setting up a post and term relation to the module: if the tester wanted a single column level control of the database then the Db module could be used. I’ve appreciated the kind reminder, in the form of an exception, that

A term with an id of 23 does not exist.

I’ve done the same error in 3 different tests, a tester error, and had not to reverse engineer the failure, possibly even looking in the wrong place, to find the problem. No time wasted.

Activate it

This low level of intelligence on the module side can be activated setting the checkExistence configuration variable to true in the suite .yml configuration file like

# Codeception Test Suite Configuration

# suite for acceptance tests.
# perform tests in browser using the WebDriver or PhpBrowser.
# If you need both WebDriver and PHPBrowser tests - create a separate suite.

class_name: AcceptanceTester
        - AcceptanceHelper
        - WPBrowser
        - WPDb
            url: 'http://example.local'
            adminUsername: 'admin'
            adminPassword: 'admin'
            adminUrl: '/wp-core/wp-admin'
            url: 'http://example.local'
            dsn: 'mysql:host=;dbname=test'
            user: 'root'
            password: 'root'
            dump: 'tests/_data/dump.sql'
            populate: true
            cleanup: false
            checkExistence: true