Implementing WPBrowser bootstrap interactive mode 02

September 18, 2016

First working code for WPBrowser interactive bootstrap CLI tool.

Not the best of UIs

The interactive console command for wp-browser bootstrap command is still in early stages in "UI" terms and it shows

[wpcept intereactive bootstrap ugly UI](http://theaveragedev.local/wp-content/uploads/2016/09/2016-09-18-at-13.45.png)

This is one of the side effects of TDD: I've run the wpcept bootstrap --interactive command just to get that snapshot and have otherwise tested its workings and side effects using tests: I've never really seen it run.

Missing pieces

The idea behind this is to enrich the wp-browser package with something that will make scaffolding WordPress plugins or themes tests easier with the added benefit to connect this to my other project of a wp-cli test scaffold command.
The leading thought in this development stage is to cover 80% of the scenarios relying on developers with more "exotic" setups to simply get down and edit Codeception configuration file by hand.
The flow so far to tap into the interactive bootstrap process is:

  • create a project composer.json file with composer init if not present already
  • include in the file the line to require the lucatume/wp-browser package with composer require --dev lucatume/wp-browser
  • wait for Composer to finish downloading the dependencies (maybe using prestissimo)
  • launch the interactive bootstrap with vendor/bin/wpcept bootstrap --interactive
  • answer the questions
  • done

The missing pieces here are:

  • an optional pre-flight check on the settings: the script will make some checks of directories and formats but not on the whole system working together; these might include checks on the database credentials and names, WordPress aware directory checks and so on
  • after bootstrap scaffold of simple tests for each suite like an homepage check for acceptance and functional tests, simple integration and unit tests
  • after bootstrap launch of the first tests
  • the pre-flight check could really make sense as a stand-alone command too allowing developers stuck in the setup later in the TDD flow process to debug it

Next

I will give the console output a first overhaul to "prettyfy" it and then move to implement the missing pieces; current code is on GitHub.