One of the conveniences about ServiceNow is the ability to easily create new functionality. This is both good and bad. It’s good when citizen developers can create repeatable items that save time and money for the business. It’s bad when those same items need to be extensible or modified, and everything is so tightly coupled, it’s difficult to do so.
Spent some time talking with some folks from SauceLabs today, who were very helpful. They pointed me in the direction of this gentleman’s repos that have tons of SauceLabs specific examples for testing.
The most interesting of these (to me) was this one. I had researched how to run concurrent tests, but hadn’t found anything that worked. The example in his code there works like a charm.
I’ve updated my basic repository to include the configuration required for that set up. Don’t worry if you don’t add “@RunWith(ConcurrentParameterized.class)” above every test. They will still work sequentially if you don’t add it.
How big of a difference does it make? A test suite than normally runs in 20 minutes ran in about 6 minutes. Huge time savings. I ran my Change Management suite (61 tests), which normally takes 2.5 or more hours and ran it in a half hour. Watching the SauceLabs test page fill up with 16 fresh tests at once is pretty cool.
I mentioned this in another post, but I also have a small, not very fleshed-out, integration with Sauce and ServiceNow Test Management. Running a scheduled job will go grab the latest 1000 tests from Sauce, and if they haven’t already been recorded as tests, it makes test case instances for them, associating them with an “Automation” test plan (which I plan to make this dynamic in the future – “Today’s Date Automation Runs”, etc.). It also brings in the links to the videos for download, and the Selenium log. The next step is using email integration along with REST to allow users to manually test with Sauce and submit their bugs to ServiceNow directly. Unfortunately, Cloudbees is blocking the normal Sauce header with it’s own header, so the “Bug” button isn’t present for me right now. Hopefully I can get them to add that for us, so I can test it out fully. Here’s a screenshot of it in action:
I realized I still had my personal Sauce account, which can make manual bugs. After a slight modification to the inbound notification, I was able to get this output:
Now manual testing in SauceLabs will simply require a step of emailing the bugs once you’re done with a manual session.
Unfortunately, this would still be manual, because the Sauce Bug API needs a specific bug id to work. You can’t query for a list of bugs. It’d be nice to have a GET/Query method that allowed for that.
Today we’re going to examine a build system I’ve been using, which I’ve dubbed “SNBuild”. Using it can help you accomplish the following:
Sound too good to be true? Well let’s take a look at this: it’s fairly simple.
Since I last blogged, I’ve been busy working on several utility projects, reading several books, and I started working out during my lunch break (since no one at the office plays board games anymore). I figured I’d share a few of those projects and ideas today.