Extending WPDb module capabilities and a thought about the API.
Testing the way
As I go over the refresh of the WPDb module part of the wp-browser add-on for Codeception I find myself researching WordPress inner workings more and more.
And as I do this I find new possibilities for the module and have to stop some times to move my development in a direction.
The code underlying the WordPress specific module is an extension of the base Codeception Db module and as such can harness its power without obscuring it: this gladdens me as I know a user knowing his way in WordPress database will always be able to use base and low methods. But I’m trying to strike a balance between two needs:
- rapid development cycles
- a satisfying API capable of handling common cases
As such I’m working on new methods to use in acceptance testing like this
$I->haveTransientInDatabase('some_key', ['foo' => 'bar']);
which is the same as the currently available
$I->haveOptionInDatabase('_transient_some_key', ['foo' => 'bar']);
which in turn abstracts the method call
$table = $I->grabPrefixedTableName('options');
$value = serialize(['foo' => 'bar']);
$I->haveInDatabase($table, ['option_name'=>'_transient_some_key', 'option_value'=>$value]);
Next
I will release a new version dealing with users, user meta and options tomorrow and the first method above will be part of it.
The idea is to cover all of WordPress default tables to allow for really expressive acceptance, and maybe functional, tests to be put in place.