Category Archives: Java

In this post I’ll give a more detailed guide for the Spring Boot and Docker initiative.

The final goal that I had in mind, was to have a Docker container that runs the packaged java application in a clean environment.
Support for remote debugging is included in the configuration, as well with both running and debug listening ports mapped/forwarded between the windows and docker machine. So in the end you can access the application as if it was running on your “localhost” 😀

After installing the Docker Toolbox (next > next > next…) we can jump right into creating a simple HelloWorld Spring Boot Web Starter project.
To do this in the fastest way, create a New Project > Maven and inside the pom.xml add the following dependency:

This is my trimmed version of the “Getting Started with Spring Boot” from the official site.
You can go ahead and run “mvn package” command to generate the application’s executable .jar file.

Now for the Docker part, let’s start with installing the IntelliJ “Docker integration” plugin. This offers easier communication with the docker and saves some time, cause you won’t have to spam “docker build” … “docker run” commands in a separate console.

In the Maven pom.xml file, you’ll need to add the following docker-maven-plugin along with a few very important configuration lines.

In the configuration we are able to specify the baseImage and imageName along with the expose and entrypoint parameters which are very common in a Dockerfile. In our case, we won’t be needing one at all, because the maven plugin will do all the work for us!

The environment variables are used to specify the server.port to run on 8888 instead of the default 8080 (yes, I’m still using Skype…)
The ports also need to be exposed from the docker container so both the server and remote debugging ports are added.
Entrypoint is basically the whole java command used to run the server, in our case the resulting “.jar” file after mvn package. It contains some extra arguments to enable remote debugging for the server.

In order to make use of this plugin we need to run “docker:build” from maven/plugins section.

After it’s finished we will have a new “spring” image derived from the default Java one. Now here comes the Docker and IntelliJ integration part.

We will go ahead and create a new Docker Deployment configuration as follows.

We can then press Play and our container will be started along with the application server. In order to be able to access the server from Windows, we need to forward the 8888 and 5005 port respectively, from the docker machine to running Windows OS (this isn’t necessary if you’re a Linux guy, because the docker-host is running natively).

To do this we can use the following commands from an “elevated windows command prompt” (just run it as Administrator):

Will now go ahead and create a new Maven project in IntelliJ IDEA 15 and then Add Framework Support and select check the Webservice client.
You can also find a link to the GitHub project at the end of this post.

Before generating the stubs, we need a few dependencies to be added in the pom.xml

but in order to do that, we need to get ourselves an instance of the GlobalWeatherLocator and furthermore, access the GlobalWeatherSoap_PortType object which has the 2 methods that we’re interested in.
A quick note here: Don’t be fooled by the “String” return type of these 2 methods, the String is actually … XML so we’re going to need a XmlSlurper to parse it and perform asserts.

Recently I had a request to have the possibility to choose which @Test to run from an external file that is human readable and easily configurable thus testng.xml was out of the question.

My first thought was: this should be easy, we can just pass a true or false value from an external file, to the “enabled” test method attribute. This approach quickly failed since the annotation’s attributes seem to accept only constants, so for “enabled” it’s either true or false, not a “superposition” of both

So I started doing a little digging and ultimately found the ITestAnnotation Transformer interface:

As you can see we initialize the tests with the enabled attribute set to false and also give them a testName. In order to have a test running, we will have to set it to true from the transform() method.

Now here was the tricky part. This needed a way to differentiate between our test methods, because annotation.setEnabled(true) will cause all the @Test methods to run.
So we had to perform a check if among the values read from the properties file, there are any testNames matching. If so, then that @Test will have its enabled attribute set to “true”.

To make this easier, we will name the keys inside the properties file with the same value as the testNames and if we have the same value, then the test is run.

1234

key=value
test1=test
test2=test2
test3=test3

For this to work, we have to Run As TestNG Suite, from the testng.xml and also pass a listener class, in our case, it is the fully qualified name of the AnnotationTest class.

Since we passed something else rather than the testName of the first test, test1() method was not run.

So we can now easily customize which tests to run from the properties file, without touching the Test methods, as long as we’re using the testng.xml and therefore this is also useful for the maven-surefire-plugin in a maven project.

Few days ago I was taking a look over a class which contained many @Test methods (from org.testng.annotations of course ) and whenever it was running, I was getting a different order of the tests in the results’ summary.

So this got me thinking and a quick solution came to mind: test dependency (dependsOnMethods / dependsOnGroups) but this would then imply that if the initial test fails, the execution would stop right then and there. I then found out about test method priority and it seems to be exactly what I was looking for and very easy to use.

Given the following example let’s see how we can obtain a desired order of execution: A > B > C

This post will show how to send values from an external file to specific WSDL tags as arguments. In this way if you have to perform combinatorial testing with let’s say, 50 different requests, instead of creating individual SOAP requests, you’ll only need one and a (rather big) testdata file.

For this example we’ll be reading the testdata from an Excel file so you should first make sure to place the Apache POI jar file in the “SoapUI\bin\ext” folder. This is the content of the Excel file:

We’re now going to Generate a TestSuite by right-clicking the WeatherSoap interface and selecting the GetCityForecastByZip operation. In the TestCase and open TestSteps and add a new step of type “Properties”, name it something like “property-loop” open it and insert a new property named “Zip”. Now open the Soap Request (GetCityForecastByZip) and right click on the question mark “?” and select GetData > property-loop> Zip. It should look something like this:

We have the request mapped to the property Zip value but now we need to also pass the data from the excel to the property. We can do this by using a Groovy Script so let’s get groovy 😀

Add a new test step select Groovy Script and insert the following code for reading an Excel file:

switch(type){case0://numeric value in Excel
result =String.valueOf((int)cell.getNumericCellValue());break;case1://String value in Excel
result = cell.getStringCellValue();break;default:
result = cell.getCellType();thrownewRuntimeException("There is no reader for this type of Excel data");}return result.toString();}

So what the above script does is for each row in the Excel file, we’re passing the value from the Column B to the Property field named “Zip” and then run our SoapRequest.

We can also disable the property and the soap request so that our TestCase only executes the Groovy Script which calls the request using testRunner.runTestStepByName(“GetCityForecastByZIP”).

So as you can see, we’ll be passing 1 argument to our readText() method, the “file” that needs to be read. We’re then using the Apache Commons IO, FileUtils library to read our .txt file so make sure you have that imported (seems that our “custom” readText() method is not so custom afterall )

We’re storing all the read content inside a string and then we’re going to do a split (a fabulous one) by the semicolon (“;”) character since that seems to be separating each individual row.

Now to find out the number of “columns” we can do another split by the comma character (“,”) since it is separating each username by its password. Of course you can use any other character for separation and then do a split by it (i.e. a pipe | or a tilda ` or anything else).

Next step will create an array of array of Objects called “data” and it will have the size of data[rows][columns] that we obtained earlier.

What’s left next is to make 2 for loops in order to iterate through the number of rows and then columns while assigning the read value to the data[][] array without the whitespaces, which will be trimmed.

In the end our method will return the “data” Object[][].

So we’re now going to use this method for the @DataProvider annotation:

Notice how the dataProvider name in the @Test annotation corresponds with the name of the @DataProvider and how the test method “loginGmail” accepts 2 String arguments which corresponds with a row of parameters from our input.txt file

In the end our test will be executed 3 times because there are 3 rows of username+password combinations which are passed from file.