The Toolkit for WordPress BDD


To do Behavior Driven Development [BDD] in WordPress, you need to get the tools! Here is the stack you should use:

Operating System

Ubuntu 16 LTS. I personally use an Ubuntu 17 development server on my laptop. You can run Ubuntu on most machines with a USB memory stick, and it’s free. I use Ubuntu on the Amzaon AWS remote cloud servers and production servers. Ubuntu is a brand, but it’s just a Debian based Linux distro, so it’s future proof. If you stopped liking Ubuntu, you could switch to another distro without hassel.

Get the stack

Once you have a machine with Ubuntu running, you can load the entire development stack by running a single command:
source <(curl -s https://raw.githubusercontent.com/johndeebdd/Remote-BDD-Setup/master/installScripts/wordpress.sh)
Directions

Test Framework

Codeception with WordPress modules - PHPunit is the standard and default library for doing unit testing in PHP. CodeCeption INCLUDES PHPunit, as well as a whole series of libraries for doing BDD.

Acceptance testing

You should use the WPWebDriver and WPDb modules. You can use Selenium to drive a full browser if you want, but generally you should use PhantomJS, because it is much faster. You can write your test in the Gherkin format, or in procedural PHP. Generally, I consider Gherkin cumbersome and not worth the candle.
Sample acceptance.yml

WP-Unit testing

You should use the WPloader and WPQueries modules.
Sample unit.yml

Where does code live?

Use a Git repo. Use Github for code that has a public face. Use Bitbucket for private repos [or pay Github for a private repo, either way].

How do you control outsourcer Git commit access?

First setup a few emails: freelancer1@yourdomain.com, freelancer2@yourdomain.com etc. These accounts are granted direct commit access to the repo. Give the outsourcer access to the email account. The repo itself can set a webhook to pull to the production server upon commit. When you want to freeze the outsourcer from the project, you just change the password on Github and email accounts. The project manager retains access to pull to production. The outsourcer can make a commit and it appears directly on the development server. When the commit is approved by the project manager, he does a manual pull to the production machine.

How does the outsourcer work on the code?

Some programmers will have their own IDE setups that they like and know how to use. Eclipse is the best free IDE, while PHPStorm is probably the best commercial IDE. If they know how to pull down from Github and run the code on a local host, great. If they don't know how to do that, setup a development server in the cloud for them. Our stack include the Codiad IDE, which is an open source IDE similar to PHPStorm. TO access it, just go to /codiad/ on your development server, it's all setup already.

How do you run the test suite?

cd /var/www/html/wp-content/plugins/{project dir}
bin/codecept run -vvv --html

How do I see the test results?

They appear in the terminal, or at http://yourdomain.com/wp-content/plugins/{project dir}/tests/_output/
Usually in the terminal you can use the up arrow shortcut.

How do I commit to the repo?

git add --all
git commit -m "some kind of message!"
git push origin master

How do I log in to the WordPress site?

You can log in by using the FastRegister plugin. Just enter an email in the sidebar form and viola! You're logged in as an admin.

How do I log in to a terminal?

The stack will preconfigured a user called "freelancer" with a password "password". Just SSH into the system without a pem file.

7 FREE Plugins

I will help you build a WordPress plugin – 100% for free – in exchange for letting me blog about the experience.


I’m John Dee – an expert WordPress plugin developer. I am going to be making 7 WordPress plugins for business stakeholders using my Behavior Driven Development / Test Driven Development method. This is an attempt to write a book on WordPress plugin development. I’m looking for business partners who wish to get involved.

My claim

Using BDD / TDD, I can decimate production costs and increase quality for WordPress plugin development. Rough guess, I can reduce costs by 90% at most enterprises.

You get


Directions for the toolkit.

  • A WordPress plugin made for you, which you then own, 100%.
  • A development work-flow for your own team to use in the future.
  • A comparison of your current work flow to other small and medium sized development teams. [Except any proprietary information]

Your requirements

  • You must come up with an IDEA for a WordPress plugin. That’s mostly it.
  • You have to pay for programmers. I am a developer – I am an expert programmer who manages other programmers [usually lower skilled, lower paid programmers, but I love working with experts too!]. If you are running an Agile team already, great! If you’re a one man shop, great! If you already have programmers or developers, great! This might be a very large cost, or a very small cost, but I promise it will be cheaper by an exponential factor than you can do on your own. Again, I will receive zero percent of this, and I’m not shilling for someone else. I prefer outsourcers, but if you already employ human beings who know PHP, great let’s use them!
  • This is for WordPress plugins! Business scripting [which is perfect for WordPress], PHP APIs in general, WP-API, PHP SPAs with WP backend etc.
  • This is for backend plugin development, not frontend theme design. Not content, not hosting – although I’ll throw in development hosting if you want it. I use dev servers on AWS, which are nearly free.
  • Assuming this is a business project, you will have to provide for all aspects of your project not specifically related to development. [i.e. if there is a marketing component to your project, you’ll need to manage that.]

Workflow

  • One of the main points I’m trying to develop is the ability to work remotely. All work is done via Skype.
  • I will provide development servers. I use
    cloud based development servers on Amazon AWS domain with some garbage like ec2-34-197-124-101.compute-1.amazonaws.com The main obstacle to doing WordPress BDD is setting up the frameworks. It’s really hard.
    That’s what I bring.
  • Code is stored on Github or Bitbucket. If you require a firewall, no problem. I make everything compatible on any site, so I don’t need access to your production servers. You can do that.
  • I am doing semi strict TDD / BDD. Programmers DO NOT NEED TO UNDERSTAND TDD IN ADVANCE.
  • I’m doing modified pair programming. I monitor the programmers and direct how they write the code. I generally check in every hour with them. This preserves my brain to take a higher level view of the project while the programmer can work doggedly on the smaller scale without worrying about the higher live architecture.
  • Toolkit is 100% open source, Codeception with WordPress module [PHPUnit etc.]

Contact John Dee to get involved.
e. johndeebdd@gmail.com
p. (702)748-5491 [call or text]

The Feature

A feature from the biz perspective

What is a feature?
A feature is any aspect of your software that is useful to you. Anything you can express, that is possible, and that you an afford, can be a feature. A bug is a feature that isn’t useful.

Since we’re talking about development, we’re discussing software features that don’t exist yet, that we’d like to build [or existing features we’d like to make better]. Often we can describe these things with should statements:

  • It should email all the clients once a month.
  • It should have a setting page in the admin area.
  • It should have a custom post type called GPS coordinates for each subscriber.
  • It should show a timeline of Civil War battles in the footer area.

The bottom line, at some point you have to have a conception of what you want in your mind. This thing is called a feature, and it’s what you want your developer to build you.

Understanding DNS and localhost [vis-a-vi WP-BDD]

The Domain Name System [DNS] is the system a browser uses to resolve domain names like generalchicken.net to IP addresses like 34.197.171.101. A server connected to the internet generally has one IP address, usually one main domain, but it can also have many subdomains. For instance, this server hosts the domains generalchicken.net and another blog, messagetothefish.com. Both have the same IP address, but different domain names.
When an HTTP or HTTPS request is sent to the server, the request should include the host header which indicates to the server what domain a resonse is expected from. A browser like Chrome or Firefox does this automatically for the user.
Internally, once the request is received by the server, a web server, like Apache, sends each request to a particular directory, based on what subdomain is named in the host header. From there, a file is activated, and in our case, passed to the PHP parser. For WordPress, it is called index.php. On most Ubuntu WordPress setups, the main domain root directory is usually set to:
//var/www/html/
and subdomains go from there:
//var/www/html/sub1/
//var/www/html/sub2/

These are the directories [for their respective domains], which will contain the WordPress root files, especially the index.php, the wp-config.php files, and the other directories like:
//var/www/html/wp-admin/
//var/www/html/wp-content/themes/
//var/www/html/wp-content/plugins/
//var/www/html/wp-includes/

Understanding this is important because if you are setting up a local development version of WordPress, you are going to want to be able to set subdomains up. Normally, you’ll have a sepearte wp-config.php file for each domain, specifying which database the domain points to.

The default setup on Ubuntu, is for the domain localhost to point to //var/www/html . Therefore, to access your local WordPress site, open a browser like Chrome, and got to http://localhost/ and you should get the WordPress install screen.

Another consideration is that most forms of testing work the best when you don’t have any state. That is, the database is either reset to a starting point, or totally scrubbed after each test. If you’re not used to this, you may accidentally delete anything you have on your site, especially if you’re using it for anything.

My personal setup is that I use http://localhost/ for unit testing, and I have another WordPress install, called http://laptop.dev/ where I have a database that doesn’t reset.

Directions: Setting up virtual hosts on Ubuntu 16.04 LTS.

Types of WordPress automated tests

state browser database SUT
WP Acceptance tests carries from test to test assumed headfull JS browser [ie. Selenium with Chrome] not reset after each test entire WP application executed with each browser call
Stateless acceptance tests tests run in isolation assumed headless JS browser [ie. PhantomJS] reset after each test entire WP application executed with each browser call
WP Unit tests tests run in isolation assume no browser or only cURL reset after each test WP application NOT executed
WP API tests tests run in isolation cURL only reset after each test WP application is executed

Tutorial: Setup cloud based Dev server for PHP / WordPress using Codeception

Part of a BDD WordPress article.

These directions will setup a a Behavior Driven Development (BDD) environment, for WordPress in the cloud using Codeception. It will setup a WordPress install in the cloud, pull down a plugin from Github, and setup an IDE as well as a test suite. You can use this dev cloud environment to engage outsourcers or remote teams.

  1. Setup an Ubuntu instance, i.e. on AWS. You should be able to do this on any cloud based Ubuntu machine or laptop.
  2. Create a local key pair on your machine and connect to your instance. This is the Amazon security authentication system. The goal is a clean Ubuntu machine. You could use another service [like Google or Cloud9] or even a localhost. Open ports 4444 and 80.
  3. Install and update software.

The IDE is at:

  • http://your-domain.com/codiad/