Chronicles of a build - the signup plugin 03

4-minute read

Some changes

The diagram I made yesterday made perfect sense then but seems a bit silly now and so I have updated it to use the standard user login page in place of a custom-built one to welcome users. The diagram I’ve changed this way:
[caption id=“attachment_119” align=“aligncenter” width=“707”]Modified signup plugin front-end flow Modified signup plugin front-end flow[/caption] Furthermore I’ve changed the type of user the plugin will manage from “subscriber”, WordPress default role, to “member”; the plugin will take care of the creation of the user role and capabilities.

Choosing a path for the first end-to-end test

From this diagram I can spot ends and choose two of them, following along flow directions, to use for the first end-to-end test.
A note about terms: an “end” is either an entry or an exit point of a software application. I find it difficult to translate this definition in a website, or in a web-application, because a website has a circular structure by definition. I choose to use the word “end” nonetheless to indicate a static situation where the ball goes back in the user field or a situation where the website, as an application, waits for the user to interact with it.
I’m choosing here the shortest path I can think of to go from an end to an other: the one that should redirect a non logged-in user to a custom subscription page.
[caption id=“attachment_123” align=“aligncenter” width=“671”]First test case path First test case path[/caption] The reason I choose this path is that I want to start small and keep things easy to begin with.

Selenium test set-up

Here I’m working on a multi-site WordPress installation on a site with no other plugins installed; you can read about my set-up here.
Once I have created a new site in my multi-site installation I can set up my first end-to-end test case.

Setting up the first test case [YouTube video link]

Before the video I’ve already set the Base URL of the test site to be able to use relative addresses in the test and renamed the test case to something that will allow me to grasp the sense of it among many others.
In this first test case two things are to note:

  1. I use waitForPageToLoad two times: this is because the plugin will redirect non logged-in or logged-in members to a custom login page. The first waitForPageToLoad is for /wp-admin page while the second one is for the eventual page the plugin will redirect users to.
  2. I use assertElementPresent to look, via XPath, for an element with an attribute id = "member_login_form" and that makes the test fail.

I choose to test for an id attribute where I could have used an assertTitle or something else to keep the test as clear as possible of localization and user options. The page could be named in any way, it’s one of the requirements, and the title could have any format; looking for text in the page with assertText would be susceptible to localization as well. Themes could wrap the plugin output in any way nesting it inside a div and the only thing I, as the developer, can really control, are the barebones HTML structures: no matter the site page, theme or options I’ve committed, writing the test before the code, to two points:

  1. the plugin will redirect users to a custom login page set by the site administrators
  2. the plugin will output its front-end view, at least the first one, inside something that has a id = "member_login_form" attribute

I now have to write as little code as possible to make this first end-to-end test pass: this means creating the plugin skeleton first. Though still not a walking one.

Creating the plugin skeleton using grunt-init

I have set up my working machines to be able to quickly setup a plugin skeleton using grunt-init and will use the template I’ve shared on GitHub in this case.
Once done I find myself with a plugin empty of any function but still listed among the site plugins and can move to code.