Some of my Selenium IDE test scripts make use of the gotoIf command. Flow control logic like the gotoIf and label statements are not part of the standard Selenium IDE core library. Like most apps these days, Selenium IDE has a method for extending the base functionality with plugins and core extensions. The “sideflow” core extension from darenderidder is an extension that provides the oft-referenced goto controls for Selenium IDE.
Adding sideflow Flow Control To Selenium
I like to keep current with any repository updates, so I use git to clone the repository into my documents folder on my Vagrant WP Dev Kit CentOS box. Using SmartGit I clone via the github URL:
This article is about my legacy publishing process for development WordPress plugins and themes. It is my workflow and it is far from perfect. It will evolve over time and I am in the midst of making several big changes using new tools to assist in the process. To get some background on the process you may want to follow along with the WordPress Workflow and WordPress Development Kit threads on my blog.
My WordPress development is fully contained in a VirtualBox running CentOS 6.5 with a full GUI interface. I am working on building an distributing some Vagrant boxes that will help others replicate the process. My base CentOS 6.5 GUI box is online but is not a full setup… yet. You can read about Vagrant in the WordPress Workflow thread.
My plugin development environment consists of a standard WordPress production build (3.8.1 today) with the typical wp-content/plugins subdirectory. On my development system I work directly inside of these directories. It provides instant access to the modified code without running a repetitive series of push/pull commands to move stuff into a “ready to review” state. I find this configuration to be far more efficient and rely on semi-intelligent scripts to help me “weed out” the development environment when building the production-ready kits. As a last step before production I have a test box on a remote server where I install the production releases as a clean last-minute sanity check. This will migrate to a Vagrant-based “clean production simulator” to provide more robust testing.
How does my “inline production” setup look?
The Build Scripts
The top-level build scripts go in my ./wp-content/plugins directory. That is not exactly accurate. I should say that symbolically linked file pointers (symlinks for Linux geeks… or shortcuts in Windows lingo) go in that directory. This includes the makezip, update_wrepo, exclude and common files that are part of the legacy/publisher section of the new WP Dev Kit I’ve published on Bitbucket.
Within each plugin subdirectory I create an assets subdirectory. This is where my “build and production helpers” go. My scripts specifically avoid this directory when packaging the “for consumption” products. Within this directory I currently store things like raw image assets that typically get pushed the WordPress Plugin Directory, a full copy of the WordPress svn repository for any plugins published there, and other “goodies” I need for production that I do not distribute. This is where my new Grunt and other build helpers will go.
Published Files Store
There is a separate directory under my home directory, ~/myplugins, where the published files go. This helps keep my production files separate from the main plugins. This will eventually change as I improve and streamline the process.
NetBeans “Push” Project
I also have a special directory under my home directory where I keep non-WordPress NetBeans projects. One of those projects is a private project named “csa_licman”. One of the many things this project does, which will also be changing, is sync any changes I make in the subdirectories of the csa_licman project up to my live server. I use this to “publish” my premium add-ons to my live server. I will not cover that part of the project here or the NetBeans automated FTP push setup.
You can find details on getting NetBeans projects to watch a directory and FTP files elsewhere on the NetBeans site. I will be changing this complex part of the system to automated Grunt processing in a later revision to the WP Dev Kit. For now you can keep the myplugins directory and manually FTP files from there to any private directories.
Keep in mind that anything going to the public WordPress Plugin Directory will be handled via the legacy update_wprepo.sh script. The NetBeans push project is only for my premium add-on packs that are not hosted in the WP Plugin Directory.
My tool kit currently consists of:
git – for managing my code repository. I find it faster and lighter than svn.
svn– solely for publishing to the WP Plugin Directory.
smartgit – my GUI to help me cheat with git commands, I am MUCH faster with the GUI.
NetBeans – my IDE setup specifically for PHP development with heavy use of phpDoc hints in my code.
Firefox with Firebug – my test and development browser because Firebug is the easiest-to-use development tool set.
command line with Bash – the Linux command line for executing my Bash scripts, most of this should work on OSX as well.
Using The Legacy Publisher
Here is how I setup and use the legacy publisher scripts in my setup. I call them “legacy publisher” scripts as I am learning Grunt and working toward a more intelligent processor. The legacy publisher is based on simple Bash scripts which can be complex to configure and extend. Grunt provides a managed system that will fetch various plugins to do a lot of cool stuff that would take me far to long to replicate in Bash. Why re-invent the wheel?
After I get my new dev box setup and I have WordPress up-and-running and my development plugins in place under the wp-content plugins directory I attach my legacy publisher kit. I am not going to cover the NetBeans push setup under csa_licman though you will see it referenced in the shell scripts. Always answer “n” to “publish to live server” when running any of the legacy scripts and you will not have issues as that part of the script will not be executed.
Under my login I use git to fetch the WP Dev Kit from Bitbucket, setup my published files directories, I then link the legacy publisher kits into my WordPress plugin directory:
git clone email@example.com:lance_cleveland/wp-dev-kit.git ./wp-dev-kit
ln -s ~/wp-dev-kit/legacy/publisher/*
I am now ready to use the legacy kit to build my production zip files and publish them by hand to my server or use update_wprepo.sh to push them to my WordPress Plugin Directory listing.
Simple Self-Hosted Plugins
My premium add-on plugins are the simplest setup for this environment. Once I have my legacy publisher scripts in place I can create my base plugin files right in the plugin directory. I edit my readme and php files, test locally, and when ready I publish them in one step with the makezip command. Since I have a NetBeans automated push project I can answer “y” to the publish to live server question and get the files over to my server. If you do not have this setup you can answer no and manually FTP the files in ~/myplugins to your final destination.
WordPress Hosted Plugins
WordPress hosted plugins, such as the Store Locator Plus plugin, require a bit of extra work to get them ready for production. After the initial setup is in place I can update the production release using the update_wprepo.sh script. In this setup I use the assets subdirectory to assist in the production. It is where the svn repository lives that gets updates to the WordPress servers.
I start with my plugin directory in place and build the setup necessary for the legacy script to publish to WordPress:
echo '<?php // Silence is golden.' > index.php
svn co 'http://plugins.svn.wordpress.org/store-locator-le/' svnrepo
My plugin is now ready for publication. I go to the wp-content/plugins directory and run update_wprepo.sh and answer the prompts whenever I am ready to push to the WordPress plugin directory. The process also build a local zip file in the ~/myplugins directory so I can keep a copy on my servers. The update_wprepo.sh script will update trunk, create the version branch and even try to clean up any tags or branches if a push of the same version has failed previously.
WP Directory Marketing Assets
Getting asset files into the WordPress repository is also part of the script. This is the preferred method for storing your plugin banner and screen shots as it lists them on the WordPress site without filling up the .zip distribution that goes to the client. With the legacy publisher it is easy, though a bit of a manual process. I store my banner and screenshot files in the ./assets subdirectory (note to self: should create a wp_marketing_images subdir). Since the assets directory is never part of the published file set they are ignored. To add assets to the WP Plugin Directory publication I create an assets directory under the svnrepo, copy over the image files I want, and run svn up from the svnrepo directory.
The following scripts are included in the legacy/publisher directory in my WordPress Dev Kit:
After all the discussions about testing web apps and working with a variety of relatively horrible app testing platforms, I have been learning Selenium IDE. Selenium IDE is the “little brother” of the full blown Selenium Web Driver. Where Web Driver is a robust client/server framework with distributed testing and full test logic options, IDE is a simple light weight scripting plugin for your browser.
That is what I like about IDE. I know what it is and don’t push it beyond those limits. It is basically a “web input” record & playback utility with a few commands added to make it a rudimentary testing system. I now use it for testing the WordPress plugin base functionality with limited effort. Spending an extra 10 minutes writing a test case pays off in numerous “one-click-and-done” script runs in the future when I want to do something like “make sure the Pro Pack name search is not broken” after a new release.
The premise is simple, when you add Selenium IDE to your browser as a plugin you get a menu option in the browser “Selenium IDE”. You can record a script by clicking a record button, “do you web thing”, then stop recording. You now have a script outline. Click the “run this button” on the interface and the script runs again.
One caveat. The recorded scripts are not very good. They get the job done for a quick start, but you are much better off spending and extra 5 minutes and writing the test commands by hand. They are far more efficient and accurate.
When you select it a new popup window opens with a simple test case table on the left and commands table on the right. The Test Case table is mostly for Test Suites (groups of test cases you run in sequence) so we’ll ignore it for now. On the right side is the commands and it start out with a “blank slate” of commands. I have another blog post about the commands I use that handle 90% of my test scripts that you can use as a quick cheat-sheet.
To start a new script you use the right-side command window. The general command sequence is to click on a new blank line, start typing a command in the bottom-of-screen command box and press enter to auto-complete, enter a target which identifies an on-screen element in jQuery-like fashion, and a value for certain commands. Repeat.
An Example Session
Here is how I create a simple test to make sure SLP Pro Pack is installed and allowing lat/long editing to occur:
Click the first blank line.
Select command on the bottom entry form.
Start typing “open”. This is the “open a web page in same window” command.
Select target. type the relative path (you can use a full http address, but I want my scripts to run on any server)
Click on the next blank line & continue building out my script.
I won’t bore you with each command, here is a screen shot of the Pro Pack Edit Location lat/long script that is also on GitHub.
waitForElementPresent = pause execution until something that needs to be on the page is present
clickAndWait = click an element and wait for the page to reload before continuing
type = type text into an HTML element, like an input box
assertValue = flag an error and STOP SCRIPT EXECUTION if the value does not match
For items without a discrete name or with multiple instances you can combine XHTML-like references with other elements. Two key things to remember about this, using a single-slash means “exactly at this point in the document hierarchy and double-slashes means “first found”. For example /table/thead/tbody/tr is THE first row after the table, thead, tbody elements. If any are missing it will fail. In contrast /table//tr will meant the first table row that can be located after the first table in the document. I often mix-and-match “select by name” and the double-slash “first found” options so that something like this shows up:
This is useful in WordPress where I can never be certain that a theme will not change the page structure. In this case it says “find the first table element with an id set to foo, within that find the second tr element (since a theme/plugin may throw in some thead or other element I continue the // format), find the second th element in that row, and select the first hyperlink with a class set to ‘bar’.
Targets take some getting used to, but luckily you can test your “guess” at the right path after it is entered with the “find” button that will go show you which element it thinks you mean on the page that is currently rendered in the browser window.
What I’ve Learned
A couple of important things I’ve learned along the way. First, use waitForElementPresent judiciously. I usually put this in place before I interact with the first item on the screen. The “…AndWait” commands wait for the page to load but with so much jQuery page loaders out there it is common for the element you need to not be ready when the page first comes online. The “waitFor…” commands can wait a long time and will not always flag an error if they time out. Use “assert…” whenever something critical must be on the page or to flag a script as failing. “assert…” is NOT the only way a script will fail, which is a feature I like about Selenium IDE. If you try to click an element and it is not there it fails the script but tries to continue running. This makes it very easy to write light-weight test scripts.
Overall it is not as robust as many testing platforms, but that is a good thing IMO. Because it is light & easy you can get Selenium IDE in place and get your first test scripts online in well under an hour. That means you really have no excuse not to be doing at least RUDIMENTARY repetitive task testing on your web apps.
I’ve started using this to test my WordPress plugins and try to add at least one new short test case in each plugin release. It adds about 10-15 minutes on average to the test cycle but it means one more feature is tested before each release. Even now with just a dozen test suites I’ve prevented at least two significant functional bugs from getting out to the public.
Use Selenium IDE and do some web tests. The user community will thank you for it.
I’ve been using Selenium IDE for a few months now with very simple test scripts. Mostly scripts I’ve recorded to test my WordPress plugins. They are not very sophisticated, but as my release schedule has increased so has my need for more robust testing. Unfortunately the Selenium IDE 2 documentation is sparse at best. Maybe they have a complete list of commands and how they work, but I can’t find it.
So I decided to create my own Selenium IDE commands list. This is my cheat sheet and is based on my current knowledge as an end user. It may not be accurate, so always check what you read here before applying it to a production test suite.
Using Selenium IDE
One of the first lessons I learned is that recording/playing back scripts is a great way to get started. The second lesson learned seconds later is that the scripts are far from perfect, very inefficient, and always need editing.
Add wait commands, it is key to successful tests. Always make sure an element is loaded before running full speed through the script.
Edit the first couple of commands to go directly to the test URL. Often the scripts start elsewhere.
Realize this is not a full programming language. Out of the box it does NOT support if, goto, or loop constructs. It is a pure linear command execution. If you need more you should get an add-on OR use the full Selenium RC line.
Selenium IDE Commands
(that I use)
locator – an element locator
Make sure an element is present, if not fail and abort the remainder of the test.
I use this to make sure that a previous test suite or action did what I expected. If not, something is horribly wrong. Assert commands tell Selenium IDE “hey, something bad happened… stop testing”.
value – what you expect the value to be set to
This is a recent addition to my Selenium IDE arsenal. I use it to check custom CSS rules and make sure that when I tweak a CSS rule via my admin panel textarea field that it makes it to the front end. I check the computed style of a specific element and make sure the attribute is set as I expect. For example, check that the final style sets a font size to 48px.
This is a great way to force a checkbox on. The mirror command is uncheck.
target: you element finder i.e. name=checkbox_name_property
value: n/a (leave blank)
locator – an element locator
Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad.
A good idea to use waitForElement to make sure your locator is present before doing this.
url – the URL to open; may be relative or absolute
Opens an URL in the test frame. This accepts both relative and absolute URLs. The “open” command waits for the page to load before proceeding, ie. the “AndWait” suffix is implicit. Note: The URL must be on the same domain as the runner HTML due to security restrictions in the browser (Same Origin Policy). If you need to open an URL on another domain, use the Selenium Server to start a new browser session on that domain.
selectLocator – an element locator identifying a drop-down menu
optionLocator – an option locator (a label by default)
Select an option from a drop-down using an option locator.
The easiest way to select an element on a pulldown list is:
target: id=<input id>
value: label=<text string of item to select>
Here are notes on the selectors from Selenium IDE:
Option locators provide different ways of specifying options of an HTML Select element (e.g. for selecting a specific option, or for asserting that the selected option satisfies a specification). There are several forms of Select Option Locator.
label=labelPattern: matches options based on their labels, i.e. the visible text. (This is the default.)
value=valuePattern: matches options based on their values.
id=id: matches options based on their ids.
index=index: matches an option based on its index (offset from zero).
If no option locator prefix is provided, the default behaviour is to match on label.
locator – an element locator
value – the value to type
Can also be used to set the value of combo boxes, check boxes, etc. In these cases, value should be the value of the option selected, not the visible text.
This is what I use to “type” data into an input field.
locator – an element locator
Uncheck a toggle-button (checkbox/radio).
This is a great way to force a checkbox off. The mirror command is check.
target: you element finder i.e. name=checkbox_name_property
value: n/a (leave blank)
locator – an element locator
true if the element is present, false otherwise
Verifies that the specified element is somewhere on the page.
I try to use this before I click on anything, enter input values, etc. Often an element is not loaded yet. This waits until it is (or fails).
Checking if a hyperlink that contains specific text is a good way to manage the AJAX operations of WordPress categories. You can use the following command set:
We often run into sites that do not load the Store Locator Plus map ever since our version 3.X update that uses late loading to be more intelligent about how scripts are loaded. Here is an excerpt from an investigation with a client installation related to this issue that will shed some light on the problem.
I need to create an option for “early loading” and “late loading” of scripts. There are simply too many themes or plugins that break late-loading plugins.
Early loading means we load all of our scripts on every single page, regardless of whether the page needs it or not. The bonus… it always works. The downside, it is slower. Especially on very busy sites.
However, in the past 6 months since we changed to the smarter model we have come to realize there are THOUSANDS of plugins or themes that are just not well engineered. Thus we realize we must engineer our plugin to be even smarter.
With version 3.2 Store Locator Plus will default to “early loading” and always load our scripts. It will work on more sites but be slower. The Pro Pack will have an option to turn on “late loading”, removing the early loading and making the plugin more efficient. If it doesn’t work (like on your site) you simply uncheck the box and go back to the slow but working method.
In the long run you are better off using only themes and plugins that do not break plugins that take advantage of the late loading feature available since WordPress 3.2. Your site will load faster as more & more plugins start using this methodology.
The short version, it is going to take quite a bit more effort but this is the best solution. The fix for your site is to select a theme & plugins that are well engineered. Your new site is not working because the theme is not calling the proper WordPress 3.2+ action hook sequence.
The bottom line of all this. Some plugins and themes are not well engineered. When we release version 3.2 of SLP we will provide an option to “be slow and work around bad plugins/themes” or “be fast, I am using a great theme and well designed plugins”.
Some themes, it turns out, do not properly support late loading scripts. In order for wp_localize_script to work after a shortcode has been rendered the script must be loaded in the footer, or “late loaded”.
The first thing to do is ask your theme provider to update their theme to properly support late loading and localized scripts. Then check back here for updates. We are working hard to make our plugin compatible across as many themes and plugins as possible.
A follow-on discussion with our client about why we do late loading and why “other plugins don’t seem to break but SLP does”.
Most plugins will not have a problem because they are not nearly as complex as Store Locator Plus.
1) Register the script early in the WordPress process.
3) Enqueue the script.
I know because I did the same thing 2 years ago until I discovered localization of scripts and spent time learning how it works and why it is better.