There is general help around the Internet and the ServiceNow community specifically, but there isn't much specific "how-to" on test automation, and I'm sure there's somewhat of a demand for it. Or at least, one would think there would be. (In fact, there were two sessions at Knowledge15 regarding test automation: one in Ruby and one in Python. Both were interesting and informative.) Face it, who wants to run through test plans over and over again? Or worse yet, who wants to not test their product and let it crash and burn spectacularly in production? In this post, my aim is to guide you through:
- Installing the latest Java SDK
- Downloading and installing Maven
- Downloading and installing GitHub or Bitbucket
- Downloading and installing an IDE such as Netbeans.
- Creating a test automation project
- Creating page objects
- Using SauceLabs for testing
Note: This is a combination of several posts from my existing blog, baugs.wordpress.com. I'm going to consolidate many of my posts from that site into this one (and sensibleservicenow.com) over the next few weeks.
1. Installing the latest Java SDK
Long ago when I first studied Computer Science, the primary language taught was Java. And it was taught on NetBeans. So it's what I'm familiar with, and as the advice in the Pragmatic Programmer says, "Use a Single Editor Well".
The SDK can be found here. Click "Accept License Agreement" and download the appropriate version for your computer. The installation is pretty straightforward.
2. Downloading and Installing Maven
There are numerous tools for building and compile code, but Maven was the first one I learned. Gradle is a powerful one, and ANT is the default that comes with NetBeans. You can download Maven here.
After you download and unzip the files, press WinKey + Pause, selected the "Advanced" tab and "Environment Variables", and add the location of the maven binary folder to the "Path" variable.
You'll know you were successful if you open a command prompt (WinKey + R, then type "cmd") and can type in mvn -v and get output.
Easy peasy.
3. Downloading and Installing GitHub (or Bitbucket)
Source control is vital for your sanity. It's also going to be vital later when we're using something like Jenkins to build our project automatically for us.
Both Github and Bitbucket are free. The advantage to Bitbucket is you'll get 5 free private repos, where you get none with Github unless you pay. My company has been using Bitbucket because it is more cost effective for a little over a year now, and I enjoy it. Download GitHub for Windows here or GitHub command line here, and run through the installation. I prefer the command line greatly, and it's what I'll use for the tutorials. You don't need to know that many commands, honestly.
Once it's installed, open up a shell with Git. Navigate to a directory you want to use for development and type git init. Congratulations, you've started a repository. If you want to keep in at a remote location (which you will), go to GitHub or Bitbucket and under your account, add a new repository, with a name that matches the directory where you called "git init". You will receive instructions for adding the remote origin to your local repo. It should look something like git remote add origin URL_OF_YOUR_REPO.
If you want, you can always clone my existing repo: git clone https://github.com/jmbauguess/ServiceNow-Selenium-Test-Runner.git
4. Downloading and Installing an IDE (such as NetBeans)
Download the IDE here. Installation is a breeze, so I won't go into any detail. If you cloned my repo, go open the project "seleniumservicenow". Otherwise, proceed to step 5.
5. Creating a Test Automation Project
Assuming you didn't clone my repo, and want to do this entirely on your own, use NetBeans to create a Maven Java project.
Now we need to create some packages. Under "Test Packages", you'll want to right-click and create a new package. Typical naming convention is com.your-company-name.package-name. For instance, com.your-company.servicenow-tests. You'll want to create packages beyond that, such as com.your-company.servicenow-tests.incident, com.your-company.servicenow-tests.change, com.your-company.servicenow-tests.request, etc.
Under the base package (com.your-company.servicenow-tests), I like to make two classes: BaseTest, which will be our base page object, and BaseServiceNowTest, which will be what runs our actual tests.
Take a look at those classes in my git repo, because they are quite long to go over entirely in this post.
6. Creating Page Objects
The Page Factory method of testing allows you to define a Page Object with page components that you have predefined, and instantiate that page during tests. It's a very useful pattern for testing. However, page object classes can be a pain to make, especially for something as large as some ServiceNow forms. Think of how many possible fields there are on a change request or incident!
Fear not, I've created a fairly simple way of generating these classes. Download this update set, install it on your dev instance, and run the scheduled jobs within it. You can then go to the tables in the update set and copy the code into your java classes. Aside: I wish I had thought of doing that before I wrote my first test. I manually created my first page object.
Change the system properties to be whatever language you want ('java', 'javascript', 'csharp', 'python', 'ruby', or 'protractor'). It defaults to 'java'. You can also set if you want your variables camel cased or not. Once you run the jobs, the tables will be populated, based on the language you picked.
You may wonder about the "Span" objects I create with the class. I did that after noticing some differences in how the inputs were classified as mandatory or read-only in different browsers (namely IE). The one consistency was the "span" tag in the label of the element. You know, the one that turns red when a field is mandatory or yellow when it's read-only? It may seem redundant, but it's reliable.
Once you've got page objects, you'll need to instantiate them. You can see how this is done in the sample code in the repo, but I'll paste it here since it's short:
PageFactory.initElements(driver, PageObject.class);
7. Using SauceLabs for Testing
Theoretically, you can stop with step 6, and just write test classes that run locally. That's perfectly fine and valid. However, using SauceLabs gives you a whole arsenal at your disposal. For starters, SauceLabs partners well with Cloudbees and Jenkins, which is what I use. Secondly, it records your tests in video format automatically! Finally, it's free...to start. I'm not sure how much the plans are (since I'm not privvy to what my company is paying).
Having output like this is pretty nice:
Once you've signed up for a free account, copy your account name and account key. You'll need that to create the remote web driver. In a "setup" method in your test runner class, you'll need to create the RemoteWebDriver using that information for authentication. Again, the repo has specific examples of this, and here's a brief snippet:
A few notes:
- DesiredCapabilities in this instance is getting System Properties from Jenkins. If you're not using Jenkins, you'll need to use a different set up, which is demonstrated fully in the respository.
- PageSpecificSetup is a method which I implement in every class which extends this BaseServiceNowTest class. It creates page objects and logs in.
- The "authentication" object is a SauceOnDemandAuthentication object, which accepts the user name and access key as parameters.
Here's an example of my pageSpecificSetup for one of my Change Request tests. Since the ChangeRequest page object class extends my base test, it has access to the login method, which I have on my BaseTest class.
Hopefully this is enough to get you started. In the future, I will posts some test specifics: Organizing your test with methods, What to Test/What Not To Test, Model-Based Testing, Right-Clicking on elements, Impersonating Users, Handling Emails, and handling Service Catalog (which has different elements and behavior than normal forms in ServiceNow).
Thanks for reading!
