# wp-browser is now compatible with Codeception 2.3

## The first piece

In my last post I’ve laid out a “to-do list” of things coming to wp-browser; first among those is Codeception 2.3 compatibility.
So here it is.

## One bootstrap to rule them all

I’ve updated the code to play nice with Codeception latest version and try to tap, as much as possible, into its new powers.
Notable among those changes the init template system: it allows third-party developers to create initialization templates that Codeception will detect and offer to users as an option.
I’ve replaced the two distinct bootstrap commands wp-browser was previously offering with a single “template”, in Codeception terms, that makes the setup a bliss:

mkdir project
cd project
composer init
composer require --dev lucatume/wp-browser
vendor/bin/codecept init wpbrowser

And then it’s just a question of answering some questions:

Support to scaffold tests in the “alternate” version is still there and is now covered by some questions about the suite names; so acceptance tests can be called “UI”, functional tests can be called “service” and the integration/WordPress-unit suite can be called… whatever.

## wpcept is dead, long live codecept

Anyone practical with wp-browser will know that since its humble beginnings wp-browser shipped with its own wpcept CLI command.
I needed a way to add commands and functionalities specific to wp-browser and WordPress to the package and felt Codeception did not offer an easy enough way to do so.
For a long time users would deal with the “strange couple” of the wpcept and codecpept command creating WordPress specific test cases with the first:

wpcept generate:wpunit integration SomeClass

and running the tests with the second:

codecept run integration

No more.
Latest version of wp-browser will still support the wpcept command as a mere alias of wpcept and will annoyingly remind users that codecept is the way to go.
When bootstrapping wp-browser in a new project using codecept init wpbrowser the suite additional commands will be added to the global Codeception configuration file (codeception.yml) to have previously wpcept exclusive commands available on Codeception executable; before:

wpcept generate:wpunit wpunit Something

After:

codecept generate:wpunit wpunit Something

Should a project have been scaffolded before the release of this version having wp-browser commands available on the codecept binary is as easy as following Codeception guide to add custom commands, in the codecepion.yml file add:

extensions:
commands:
'Codeception\Command\GenerateWPUnit',
'Codeception\Command\GenerateWPRestApi',
'Codeception\Command\GenerateWPRestController',
'Codeception\Command\GenerateWPRestPostTypeController',
'Codeception\Command\GenerateWPAjax',
'Codeception\Command\GenerateWPCanonical',
'Codeception\Command\GenerateWPXMLRPC',
'Codeception\Command\DbSnapshot',
'tad\Codeception\Command\SearchReplace',

## There will be bugs

It should come as an implicit statement yet it’s worth pointing it out: stuff could not work as intended.
In that case open an issue on wp-browser repository and tell me a good story.

## Next

There’s a to-do list to tackle so I’ve got my hands full for some time.