Introduction
This is the first article of at least a few that I’m planning to write around how IDE plugins may be leveraged in internal test automation frameworks.
The goal is to draw attention to IDE plugins as a means to simplify and quicken the test automation process. Also, that such plugins are applicable not only for public libraries and frameworks, but also to internal DSLs, services, etc. And to see how my current ideas would’ve been useful in the past when I had no clue about IDE plugin development. 😊
In each article I’ll outline parts of TAFs and present one or more ideas, or variations of the same idea. The plugin features I’ll show will mostly center around actual test code and test data, but will include other areas as well. Many of them may use Gherkin examples because over the years I worked a lot with Cucumber.
Although, these ideas may be used in back-end, front-end, etc. development, I’ll focus on test automation in these articles. With all that said, let’s see an actual feature.
Quick navigation to pages on a test environment
Let’s take a hotel accommodation website as the domain for this first feature, and to build up the context, let’s say it has the following parts:
- landing pages for geographical entities like country, city, neighbourhood, etc., each with its own unique ID and/or URL path.
- points of sale (POS) consisting of the website language, currency, etc.
- test environments: Staging, Pre-production, Production
Now let’s have this simple Gherkin Scenario:
Scenario: City page banner
When I open the Szeged city page
Then ...
A more specific version of this could be adding the POS information too:
Scenario: City page banner
When I open the Szeged city page on the NL POS
Then ...
Let’s say this scenario fails on pre-production, and you are investigating why, and comparing the page on each environment. Normally, the process of opening these pages may look like this:
- you look up the city ID
- you open/switch to your browser
- you open each page individually (maybe from a saved location because you wanted to save time)
In a domain like this, it is not a bad thing if you have some information (IDs, URLs, etc.) in muscle memory (speaking from experience), but this process of opening pages could be made simpler.
There is an IDE feature called Line Markers or Gutter Icons. One of the most common occurrence of it may be the green play icon with which you can execute test methods.

Such line markers may be assigned to arbitrary elements in an editor with custom text, icon and behaviour.
I’ll show you a few variations on what a line marker could look like for opening pages in a web browser.
General appearance
So, we want to have such line markers for the I open the [CITY] city page
and I open the [CITY] city page on [POS] POS
steps.
As for the icon to display you can choose any that is bundled with the IntelliJ Platform, or you can design and draw your own custom SVG icons. For the tooltip text, you can use any plain text but make it concise and descriptive.
For starter, I picked the generic globe icon:

Test environment options
Our goal is to be able to open the page quickly on the environment we select, so the marker must present us a menu of options, one for each environment.
The options may look simply like this:

If you need more information, you may also add details you need, like the city ID, when e.g. each environment uses different IDs for the same entities (speaking from experience again):

URL building for the popup menu options
After discussing this article with a few people, the question of how the test environment configuration (domain, URL, actual URL building logic) is stored and retrieved came up multiple times.
There are a couple of options, and all of them depend on the type of project you are working on, how often the URL templates change on your project, and maybe other conditions as well.
The following list is not comprehensive, but you have at least these options:
- store the configuration in the plugin repository itself, with optional customization for users, on a separate IDE Settings page,
- store the configuration in your test automation project,
- retrieve the configuration from a remote endpoint.
The configuration file may be a simple .properties
file, or a more complex .json
, .yaml
or some other type of file too.
The URL building logic may be:
- a (simplified) re-implementation of your project’s actual URL building logic,
- if the URL building is released as a separate package (e.g. in an internal Maven artifactory), you can use that package as a dependency in the plugin project.
Further customization
When it comes to more specific variants of the I open the [CITY] city page
step, like also specifying the POS, you can go further with the customization to have a better user experience.
For example, instead of using a generic icon, you can display the country flag of the point of sale the step mentions:

Or, if you have a default POS used when it is not specified in the step, you can use the country flag of the default point of sale, let’s say Ireland.

Who may benefit from this feature?
I think both newcomers and long-time, experienced members of a project would find this feature useful.
It might be of more help for new team members who are still learning the environments, the structure of the project, and what and where to find.
But, later it can still cut down time on opening certain pages and tools from this popup menu with just two mouse clicks.
Closure
These were just a few simple ideas for the options of opening a page, but it can be customized even further based on your project’s needs. Let me mention a few off the top of my head:
- Currency, MVT (multi-variant test) ID, language, etc. can be extracted from the step and used to build the URL behind the options.
- Depending on the information and details in the step, you might have more than 3 options in the menu, e.g. to also open other internal services, like to open the details of an MVT.
I hope this gets you thinking about what kind of IDE support your test automation framework could use, and how even such a simple action could get simpler.