Tag: CICD

Continuous Delivery – OPA and Selenium, NodeJS and Jenkins #6

Continuous Delivery – OPA and Selenium, NodeJS and Jenkins #6

Previous parts to this series (part one, part two, part three, part four, part five) have spoken about the different tools to test Web Services and HTML Interviews for Oracle Intelligent Advisor. In this post, we will see how a more complex tool can allow the team to perform larger-scale and more sophisticated tests when coupled with Jenkins. In this case the learning curve is more challenging, but often there are already resources available to help the process.

In common with other chapters in this series, the platform includes NodeJS, and this time we have added selenium as well as (for demonstration purposes) the Mozilla driver (also known as gecko driver). The preferred choice of scripting tool is very much up to each developer, however the screenshot below shows a simple piece of NodeJS code to implement something similar to our previous examples.

Working with Selenium WebDriver in this way has a number of challenges in respect of Oracle Intelligent Advisor, the most commonly cited being the dynamic nature of classes and identifiers in the HTML page. As a result, simple selectors such as the following are not advisable since they are not reliable and will change as you make modifications to your Screen:

driver.findElements(By.id("opmCtl2"));
So instead, as highlighted in the example video above, you end up working with XPath identifiers which are long and laborious to write (of course you can use tools to help you find them):
driver.findElement(By.xpath("//label/span[contains(text(),  'Where are you travelling from' )]/../../../div/div/select/option[text() = '" + myJourneys[journey].origin + "']"));
This is doubly frustrating because obviously this is language specific, and if you need to test the Interview in several languages then you will need different identifiers. There are a few things that can help, including the good news that Google Chrome Console accepts XPath selectors so you can test them to see if you have “found” what you are looking for:

In the screenshot above, an XPath selector (note the $x(“”) syntax) has been entered and the response is an option from the array of options in the Select control “Where are you travelling from”. So I can use this selector to be sure I am populating the Origin attribute on the Screen. There are other tools of course, such as the Selector Gadget Chrome plugin, that can help make it easier. You might also think about using JavaScript Extensions to add a custom style to elements of your page to make them easier to find in Selenium. But I do think this is an area where improvement is needed.

Working with this platform has the  added benefit of being easy to integrate into Jenkins, as we saw earlier in the series as well. Since we previously organized running Newman as a NodeJS Build Step in our Jenkins Project, we can do the same with our Selenium code, in a quick and dirty example.

Jenkins Job Running Gecko

A Jenkins job is running our tests…

Jenkins Job Output Gecko
And the console output in Jenkins is telling us the details. Now that Jenkins and NodeJS are playing nicely, you are ready to set up your environment further (with multiple nodes, ChromeDriver, IEDriver and all the other browser drivers. But for now, we say goodbye to this series of overviews of how Oracle Intelligent Advisor can be part of the big bad world of CICD!

Continuous Delivery – OPA and Selenium, NodeJS and Jenkins #5

Continuous Delivery – OPA and Selenium, NodeJS and Jenkins #5

Part five of this series moves away from the testing of Web Service-based projects to Interview-based. Interview projects present several different challenges for testers. Let’s take a look at some of them here, based on common tool requirements, and focusing on tools like Selenium IDE.

  1. The need to test quickly and often, usually repeating a set of operations to ensure that the Interview is functioning (so, opening a debug session and clicking through the different steps in an Interview, repeatedly, for example.
  2. Testing the Interview on a variety of different Web browsers, to doing the same as in step one, but on multiple platforms
  3. Automating all of the above, so that no time is wasted actually clicking though all that.
  4. Ability to ascertain whether things have gone according to plan – did the Interview display expected results?

Eagle-eyed readers will have noticed that Postman has disappeared from the title in this part of the series. That’s simply because we need different tools to do this job. There are a number of ways to face up to these challenges but not all of them come with the same cost or time requirement. Firstly, we should not overlook the use of the Debugger (either directly, or with Ctrl+F5 to run the Interview in a separate browser. But given that there are no automation capabilities built-in, if we want to run automated tests we will have to look elsewhere.

Option 1 : Use the tool with the simplest learning curve. Selenium IDE is the reborn, now browser-based tool that allows non-technical people to easily create simple tests and automate them. It has built in support for recording, branching tests and creating test suites made up of multiple tests. It has a very low entry requirement, since you don’t really need to know a great deal about programming to use it.  The application is a rewritten version of the old Selenium IDE which is not supported any more and lacks the ability to work with modern browsers. Let’s look at how to use it, and then review the downsides.

The user interface is pretty simple. You can record, write scripts manually, run, pause and stop recording or executing. It is available for both Chrome and Firefox.

Selenium

Notice the logging area at the bottom where you can see what is happening. One of the nice features is that while recording, it remembers several different ways to locate each item on the page (CSS, HTML ID, XPath, Relative XPath) so you should be able to learn a lot about how to “locate” things on pages of HTML. Plus of course if you need to you can edit them. The video below shows the basic principles, and shows how you can create loops and other control structures to get the job done. Your file can then be saved (as a .side file, because you will probably want to run it using the standalone tool called side runner.

As just mentioned it also has the Selenium side-runner command line interface to allow you to run your Suites without the IDE, and also use the Selenium Grid :

Selenium Side Runner

But there are some downsides:

  1. As mentioned above, it cannot currently load data from the file system, because as a browser Plugin it has security limitations.
  2. The format of the tests is not currently exportable to Selenium WebDriver JS (but it can create code for C# , Python and Java)
  3. Not all of the Selenium language is supported / the syntax is slightly different.

It’s a great first-step automation tool and worth watching – there is a plan to migrate away from browser Plug-in to a standalone application (much like Postman did) and that will remove many of the restrictions like file system access and data-driven project limitations.

As Fiona mentions in one of her blog articles, if you want to go further than this, you probably will need something more technical and industrial. And that’s what we will see in the next part in the guise of option two.

Happy Monday!

 

PS : If you are looking to learn about NodeJS, this book is on our current reading list. Note that this link is an affiliate link, purchases made from this link give a small amount to the OPA Hub Website which is used to pay for hosting the website.

Continuous Delivery – OPA and Postman, Newman and Jenkins #4

Continuous Development – OPA and Postman, Newman and Jenkins #4

In this part of our series, we will take our existing platform composed of Postman, Newman and Oracle Intelligent Advisor and plug it into Jenkins, to allow us to run lights-out tests according to a schedule, and to enable the testing team to receive emails when the tests have completed.

For reference, the other parts of this series are here : Part 1, Part 2, Part 3.  For the record, let’s be absolutely clear about one thing – this is not the only way to automate this process, and there are other tools and platforms that can do the same job. Heck, if you are lucky you will not even have to worry about this because some other team or department already has this thought through and all you have to do is deliver projects. But you might want to understand the mechanics of this process anyway, or if you are unlucky (or lucky, depending on your point of view)  then when the musical chairs are happening and you are the one left standing so you inherit responsibility for this, at least you will have a head start.

So, off to work. Many of you will know Jenkins, the stable, powerful open source automation platform that allows us to pretty much build, deploy or test anything. The biggest bonuses of Jenkins are that it is free to use, easy to install and that it comes with an incredibly large set of plugins, which extend the functionality to include lots of other things.

If you have installed Jenkins, which is about as easy as it can be, you should find yourself looking at the basic setup screen of Jenkins:

If you are pressed for time, just accept the suggested plugins first, and then return to the list of plugins later. You will need to add several, if they are not already present. The most important one is the Node.JS plugin, since we want to use Jenkins to communicate via Newman, and you will remember from the last post in this series that Newman runs on Node.js.

 

  1. Manage Jenkins, Plugin Manager
  2. Click Available to find more plugins
  3. Filter for nodejs
  4. Select the plugin
  5. Install without a restart or with a restart as you wish depending on whether you have more to install.

Other important plugins include potentially the Email Extension Plugin which you might find useful, and potentially lots of others. You will also need to make sure that you have installed any plugins you want to use with Newman, recall that in the last post in the series you added an HTML report generation to Newman. If you didn’t do that yet, you should do it now. There are a few other settings in Jenkins that you need to setup, notably the System Admin Email Address but most of it should be fairly straightforward and you will find out that you need it when Jenkins complains.

Now you need to tell Jenkins a little more about Newman. In the Global Tool Configuration of Jenkins, via the Manage Jenkins option, scroll down to the Node.js seection and ensure you have added the details about your Node.js installation, and that you want to use Newman with it.

Jenkins Setup NodeJS

  1. Add NodeJS
  2. Give it a name whatever you would like to see in the logs
  3. Install Automatically
  4. Choose the version that you installed (the installer would have told you that)
  5. Add this to ensure that Newman and the HTML Reporter you used with Newman are available

Save all of that and you are just about ready to use Jenkins for real.

Create a new Freestyle Project in Jenkins and give it whatever name you wish. Then in the Build Environment section, ensure that you signal the need for Node.js. In the Build Step, choose Execute Windows batch command (unless you are not running windows, in which case there is a non-Windows equivalent). Add, for example, the following command line to run Newman with Node.js and use the HTML reporter, with your data file from the previous post in this series. The file name ensures that this file is overwritten each time you run this project. If you don’t you will end up with lots of files, each using a timestamp as the name, which can get confusing.

Having set up our Jenkins Project, we are going to add a Post Build Action to ensure that your team (or just you) gets an email with the report from Newman. The screenshot below assumes you have added the Extended Email Plugin mentioned above. Note the items below the image.

Jenkins Post Build Step

  1. Without going into too much detail, the extended email plugin provides all sorts of options for creating email groups and deciding which email (there can be many templates) goes to which person.
  2. This is where you add the Newman HTML report. Note the syntax of the  attachment path is not maybe what you are used to.
  3. The Jenkins build log can also be included with the mail, and can be useful if you have added many build steps and want to see what they did.

At a minimum you might want to set up an email that is sent when there are failures:

You can click the advanced options and begin that process to set up who receives emails in different trigger circumstances.

Save your project. Now, as a final point, you may which to schedule these tests to run when you are not in the office. So you can add Build Triggers from the top of the Project Configuration and use CRON-style syntax to decide when this will run.

Jenkins Setup Build Triggers

Now all you have to do is save your Jenkins Project. Of course, if you don’t want to wait until midnight you can always Build Now. You will recall from the third part of this series that my data file had an iteration in it that was set up to cause the Postman test to fail, because the journey time was too long. So, sure enough, I get an email in my Inbox:

Jenkins Email 5

The HTML report is attached to my email, and I can view the details of the failure, which is indeed the iteration 3 from my data file:

So we are now in a position to test, in an automated fashion, our Web Service from Oracle Intelligent Advisor. Although the example given was using the REST assessor, Postman will happily let you run SOAP XML calls as well, so this would be applicable too. In the next part of the series we will look at using Jenkins to test our HTML-based Interview for the same project.

See you soon!

Continuous Delivery – OPA and Postman, Newman and Jenkins #3

Continuous Development – OPA and Postman, Newman and Jenkins #3

Following on from the two previous episodes, (part one / part two) the stage is almost set to move to automation over and above the simple concept of a Postman Collection. In this chapter we will see how to use data files in Postman to facilitate making use of CSV or JSON data in a dynamic way, and we will get Newman up and running. So let’s start with the first element.

In our Collection, we currently have one request which is sending information to OPA and getting a journey time and plan back in response. Great. But we want to test our journey planner with more than one journey. And we want to be able to easily change the journeys without having to mess with our request. So this is where the ability to load data into a Collection from a text (CSV or JSON) file comes in very handy in deed. In pictures

  • Create a CSV file with your data in it. For the project used in this example we would need to have something like this

Collection Data File

Notice the headers are origin and destination. They will become variables that we need to add to our request.

  • Make sure that the request is updated

So now my request looks like this:

Request Modified

Don’t forget to save your request. Now if you go to Collection Runner and run your Collection, you can use the Select File button and select your file:

Using a Data File in Postman

As soon as you select the file, you will see that the number of iterations changes to take into account all the rows in your file. Now when you want to push a new set of journey tests all you need is to change that file. Awesome!

Armed with all of this, we can now move to the next challenge. Postman is great but not everyone wants to use the graphical user interface all the time. How about the ability to run a Collection from the command line? That would be great AND would open up lots of options to running Windows Scripts and the like. Well, the news is good. Newman is the CLI (Command Line Interface) for Postman. Setting it up if you are not familiar with Node.js can be a bit daunting, but let’s just make a shopping list first:

  1. Install Node.js (here)
  2. Install Newman using the Node Package Manager
    This step should be as easy as opening the Node Command Prompt (which got installed in your Windows Start Menu in the first part) and typing something like the following:

    Installing Newman

  3. Run Newman from the Node.js prompt to use Postman Runner with your chosen Collection and Data File using the ultra simple command line.

So the last step might look a little like the following – notice that in the command line you specify the Collection (which you must first export to a file from inside Postman) and the Data File (wherever it is – I put both files in the same location for ease of use. And once the job is done, Newman reports back with it’s own inimitable, Teletext-style display of the output. A word of advice – before exporting a Collection make sure you have saved all the recent changes!

Exporting Ready for Newman

 

Once the Collection is exported, you might run it like this. This is just a simple example. It is possible to also load environment variables and more to fine tune it.

Newman Command Line

After a few seconds we get the output from Newman. Note the 4 iterations, and that iteration 3 failed due to an excessively long journey time.

Newman Output in Teletext

Now this is of course a major step forward – running Collections from the command line, feeding in data sets just by using a simple command line switch – these features mean we can really now start to think of automation in our approach to testing this project. But we are not done yet. The output from Newman is pretty ugly and we need to change that. By installing Newman HTML Reporter, we can get a much nicer file. Follow the steps in the link and then change your example command line to something like this:

Note the new command line option -r html (which means, use the HTML reporter) and the –reporter-html-export option (with two dashes) which ensures the output file is stored in the folder of my choice. And the HTML output is so much better:

Newman HTML Reporter

What a nice document. So far so good. We can spin these collections with just a command line. But wait a minute, what about running tests when you are not in the office – sure, you could write yourself some sort of Powershell Script in Windows. But what if you wanted to run a set of tests every day at 3pm, then again on Tuesdays, then once on the first Monday of every second month…it would get quite hard. And what if you wanted to send the HTML Report automatically to all your colleagues on the testing team…but only if there were failures?

And so, we march onward to the next phase. See you shortly!

Continuous Delivery – OPA and Postman, Newman and Jenkins #1

Continuous Delivery – OPA and Postman, Newman and Jenkins #1

For the first time in a while I was working to set up an example platform for testing purposes. Whilst a good portion of it is not specific to Oracle Policy Automation / Intelligent Advisor, it seemed both useful and appropriate to document some of the ideas, steps and conversation points in some posts here on the website. So without further ado, let’s get started. In this series we will look at setting up Oracle Policy Automation, Postman, Postman Runner, Newman and Jenkins to enable lights-out testing of REST batch or XML-based projects. Then, once we’ve done that, we will extend our reach to include HTML Interviews.

Firstly, let’s get a handle on the different tools in the kit. Postman, as many will know, is a visual client for testing REST APIs – at least that is what people know it for – but it is in fact capable of making any kind of HTTP call. Although the examples here will focus on the Oracle Policy Automation Batch API, you could use it for SOAP Assess as well.

Learn About Postman

Download Postman for Windows, iOS or Linux

To make a call to an Oracle Policy Automation Project, here are the prerequisites

  • The Project needs to be deployed
  • You need to have an API Client user and password
  • You need to be able to build a sample case.

So, let’s get started!

Assuming you have an Oracle Policy Automation Hub at your disposal, or someone who can sort you out with access to one, then you need to start with the creation of an account of type “API Client”. You will need to be given access to the determinations API, for at least the Collection (or “workspace” as it is now known) and then the account needs to be activated. It probably will look something like this:

Create User for Postman

  1. Go to Permissions > API clients
  2. Create a user and enable them
  3. Select at least the workspace where your project is deployed
  4. Save the user

Your project will need to be deployed in web service mode (not Interview mode, but if it is also used as an interview that’s fine too.

Check Project Deployed

So now you are ready to fire up Postman and get this show on the road. Remember that when using the REST api for determinations, you are going to be using OAuth2 as your authentication mechanism. This requires you to make a call first to an authentication URL, and receive a token. That token is valid for 1800 seconds, and must accompany any calls you make to your project. So, here is what you need to do in Postman:

Create a Collection. To keep things organized in Postman, put stuff in a Collection. Create one, give it a good name and then later you can put all your different Requests to OPA in this Collection.

Postman Collection OK

While creating your collection, you can set up the Authentication as well. This way, any Request you make that is stored in this collection can inherit the authentication method you define. It’s easier than doing it for every request (although that is also possible).

Postman Authentication Start

Select OAuth 2.0, Request Headers and then click the Get New Access Token button. Since this is the first time you have done this, you will now be tasked with filling in a detailed dialogue to explain to Postman how to go and get the magic “token” for Oracle Policy Automation. The screenshot is accompanied by comments below for each of the steps.

  1. Give the Access Token Authentication a name. You might have multiple Hubs and need to have different data for each of them, so a name is a good thing.
  2. Select Client Credentials
  3. Enter the address of the authentication endpoint. This is something like the address above (replace “http://localhost:7777/opa19d/” with your own URL to your Hub. Note that recently the Authentication URL has evolved, and it is now versioned. Check your version of the documentation to see if you can use the new URL format (“api/version/auth”) and gradually migrate all your calls to this new format, even if the old format works for now (this was introduced in version 20A).
  4. Enter the API Client you created or decided to use
  5. Enter the password you set up.
  6. Select Send client credentials in body
  7. Click Request Token

If everything went according to plan, you should see this:

Postman Authentication OK

Obviously, click Use Token. You are now ready for showtime. You have 1800 seconds to get your first request into Oracle Policy Automation!

Finish your Collection creation (we will be using the other features of the Collection later, in the other parts of this story). Create a new Request and save it in the Collection.

Let’s assume you have a Project ready to go. If you don’t the project I’m using in this demo can be downloaded here. The Body of the request (using Raw JSON as your format) would look something like this:

{ "outcomes": [
"b_success",
"resultstepnumber",
"resultstep",
"totaltime"
],
"cases": [
{
"@id": "1",
"origin": "Miromesnil",
"destination": "Oberkampf"
},
{
"@id": "2",
"origin": "Grands Boulevards",
"destination": "Concorde"
}
]
}

This assumes your project has a boolean to indicate success and some other attributes (in my case, the step number, the step and the total time. This project calculates the time to travel between two Paris Metro stations, in the days before confinement and lockdown. There are two cases to be tested. They are based on two attributes, namely origin and destination.

The output should look something like this:

{
"cases": [
{
"@id": "1",
"b_success": true,
"totaltime": 42,
"theresults": [
{
"@id": 0,
"resultstep": "Miromesnil",
"resultstepnumber": 1
},
{
"@id": 1,
"resultstep": "Saint Augustin",
"resultstepnumber": 2
},
{
"@id": 2,
"resultstep": "Havre Caumartin",
"resultstepnumber": 3
},
{
"@id": 3,
"resultstep": "Auber",
"resultstepnumber": 4
},
{
"@id": 4,
"resultstep": "Opéra",
"resultstepnumber": 5
},
{
"@id": 5,
"resultstep": "Richelieu Drouot",
"resultstepnumber": 6
},
{
"@id": 6,
"resultstep": "Grands Boulevards",
"resultstepnumber": 7
},
{
"@id": 7,
"resultstep": "Bonne Nouvelle",
"resultstepnumber": 8
},
{
"@id": 8,
"resultstep": "Strasbourg Saint-Denis",
"resultstepnumber": 9
},
{
"@id": 9,
"resultstep": "Réaumur Sébastopol",
"resultstepnumber": 10
},
{
"@id": 10,
"resultstep": "Arts et Métiers",
"resultstepnumber": 11
},
{
"@id": 11,
"resultstep": "Temple",
"resultstepnumber": 12
},
{
"@id": 12,
"resultstep": "République",
"resultstepnumber": 13
},
{
"@id": 13,
"resultstep": "Oberkampf",
"resultstepnumber": 14
}
]
},
{
"@id": "2",
"b_success": true,
"totaltime": 12,
"theresults": [
{
"@id": 0,
"resultstep": "Grands Boulevards",
"resultstepnumber": 1
},
{
"@id": 1,
"resultstep": "Richelieu Drouot",
"resultstepnumber": 2
},
{
"@id": 2,
"resultstep": "Opéra",
"resultstepnumber": 3
},
{
"@id": 3,
"resultstep": "Pyramides",
"resultstepnumber": 4
},
{
"@id": 4,
"resultstep": "Madeleine",
"resultstepnumber": 5
},
{
"@id": 5,
"resultstep": "Concorde",
"resultstepnumber": 6
}
]
}
],
"summary": {
"casesRead": 2,
"casesProcessed": 2,
"casesIgnored": 0,
"processorDurationSec": 0.04,
"processorCasesPerSec": 45.45
}

For the sake of space, I’ve cut this off before the end. But you should be getting the idea. The output is the time taken, and the steps from the origin to the destination. There are some stations on my map which are inaccessible (because I didn’t fill in the entire map of the Paris Metro) so the boolean tells me if the route is possible, and the total time is also shown. Now that we have the basic setup, in the next part we will add

  • A test script to calculate average response time
  • A test to see if the route is possible
  • A command line to be able to run this without Postman

See you in the next part!

Worldwide
Logo by Southpaw Projects LLC