Noob Developper


Contact me if you have any questions :)

I’ve seen that there are some people coming on this tumblr (about 3-4 peoples a day) and I guess some of you may have some questions to ask me. Don’t hesitate to contact me on my gmail account : hellsing.strelok[at]gmail[dot]com. I will be happy to help you if I can. 

Currently I’m not working anymore on this project (I was just a trainee, and I succeed with that task), I’m currently searching a contract to work. I’m studying right now.

I’m currently working on some Perl for now.  It’s quite a new language for me :) Thanks for your support :)

Jacoco : Why is it different ?


Actually I’m trying to calculate my code coverage in Sonar with Jacoco. Why is it different from Cobertura or Clover ? 

  • Clover is using the source code instrumentation. Covering Selenium tests with Clover is impossible because we don’t actually test the source code but the application and what the client see and can’t see. Analyzing source code wouldn’t work.
  • Cobertura uses an offline bytecode instrumentation. That sounds better it means that it calculates the code coverage using the compiled java program. There is only one problem, we don’t work on a jar, we work on a war with lot of javascript. So that wouldn’t work either.
  • Jacoco uses an on-the-fly bytecode instrumentation and is started as a java agent attached to your JVM. That means it is able to calculate the code coverage if the agent is started before the deployment of the application. Jacoco is nowadays the only way to calculate code coverage with Selenium. that I know. 

Now you get all the differences I hope you won’t try to calculate code coverage with cobertura or clover because you will loose a lot of time trying that. 

Unhappy is he to whom the memories of childhood bring only fear and sadness. Wretched is he who looks back upon lone hours in vast and dismal chambers with brown hangings and maddening rows of antique books, or upon awed watches in twilight groves of grotesque, gigantic, and vine-encumbered trees that silently wave twisted branches far aloft. Such a lot the gods gave to me - to me, the dazed, the disappointed; the barren, the broken. And yet I am strangely content and cling desperately to those sere memories, when my mind momentarily threatens to reach beyond to the other.

- H.P. Lovecraft - The Outsider

Jenkins : Good way to test ?


So as I said at the beggining I’m currently working with a continuous integration system called  Jenkins , associated with Sonar. A way to know if you made all your configurations is to create a project on Jenkins and see if it build AND execute your tests. For example if you declared your <userExtensions> with a relative path it won’t work. You’ll have to learn the Maven variables such as ${basedir} which is the base of your project. Also remember that you never have to put a .jar directly in your project. You can declare all the dependencies right into the pom as we saw with jetty and postgresql. The risk if you put a jar in your project is that it will be embedded in your project when it’s build. Hope that could help you.

Next chapter : Code coverage using Jacoco and Sonar. If I find a way to make it work.

Pros and cons of Unit Testing with Selenium


I analysed the pros and cons of testing with Selenium RC, so that you will be able to clear your mind about that. Here you go :

Pros :

  • Simulates a real user using a real browser. Your tests won’t be unrelated to what users can do.
  • Testing the deployed webapplication. With Selenium IDE writing the tests have never been easier, you’re acting like a user and Selenium IDE records all your actions. You can then use the JUnit framework to make assertions.
  • It doesn’t matter you have in your applications (libs, dependencies) you’re testing what the client is going to interact with.
  • An easy to use maven plugin for Selenium. Highly configurable, it is enjoyable when you’re on a continuous integration system.
  • No code refactoring. No mocking framework. Since you test your webapplication by emulating a user, you don’t need to mock a part of the code or writing some reflections about GWT objects which is complex to do.
  • Compatible with scLocators and customizable by the user-extensions.js.

Cons :

  • Code coverage is harder to calculate since you don’t work on the source code, you need to use a JVM Agent (Jacoco).
  • You need to deploy your application each time you want to test it. Depending on the size of your project, it will take some time.
  • Many dependencies to add in your pom.xml to make the tests work on a continuous integration server.


Improve your Selenium tests

So here we are again, I will now show you how to improve your tests. This is an example of what you get when you export your code to JUnit 4 (using Selenium IDE)

Do you notice that, if you take this file, and add other tests in it, Selenium will open a new firefox for each test you wrote ? Isn’t that annoying and wasting your time ? Though it is using @AfterClass and @BeforeClass, there is no reason to open more than one firefox. Well here is the tip : Do not extend the SeleneseTestCase.

Why would you delete that extends ? Because it is overriding the JUnit 4 annotations. So your annotations are useless and Selenium decided that the setUp() and tearDown() functions will be executed before and after each test. JUnit requires your @BeforeClass and @AfterClass functions to be static too.

Sum up :

  • Remove the “extends SeleneseTestCase”.
  • Declare your setUp() and tearDown() functions to be static.
  • Don’t forget to annotate your tests.
  • Modify the @Before and @After into @BeforeClass and @AfterClass if needed.
  • To ensure you will run only one instance of RC, you can declare your DefaultSelenium as static. (private static DefaultSelenium selenium;)
  • Don’t forget to annotate your tests with @Test otherwise they won’t be executed.

Now you will only have one instance of firefox running all your tests. Great :3

Configuration of Jetty

Hi there,

So in case you want your tests to be fully automated, I mean you don’t have to deploy manually and everything is embedded so you don’t need a Tomcat to run on your Jenkins, you need Jetty. Jetty can deploy your .war at a certain point of the lifecycle of Maven. Isn’t that great ? So we are going to add the jetty deployment in the middle of the lifecycle, exactly after the build of the war.

Some will recommend the use of Cargo, but for my part it’s working great with Jetty (I only have some issues with the code coverage for now and I’m fixing it) and it seems lighter than Cargo (which is… A container of container ?). We are going to need 2 free ports : one for launching the server on it and one to listen on it if you want to stop the server. I’ll use the ports 9091 (jetty server) and 9092 (stop). Remember that the selenium server port is 4500.

Basic configuration :

I will now describe the plugin configuration that I made so that you can adapt it to your needs. Note that I’m using a Postgresql database so I need the postgresql driver to access my database. If you have a different type of database behind your application, you should use another driver. I used the <dependency> tag to avoid leaving the jar in the project folder (you should never put a jar in your project because it will be embedded in it and you won’t be able to remove it from the war or the server). Here as it is declared as a dependency, maven will place it in a temporary folder so that it will not be included in the project. 

So first I declare an execution : During the post-integration-test phase we will use the goal “deploy-war” which mean before the tests the war will be deployed. I gave the path of the war to deploy (using ${basedir} is useful, never use a relative path in the pom unless you want your Jenkins to fail).

The override-web.xml is the file I use to declare my datasource. Since there is already a web.xml used for the application itself. So I had to override the basic web.xml. I will show you how to declare your datasource later.

After that it’s a basic implementation of the connector that’s the way you should use it. I don’t think I ever changed that. 

Datasource declaration :

  • jetty-env.xml : This must be placed in your src/main/webapp/WEB-INF/ and is automatically read by jetty.
  • override-web.xml : The file you declared in your pom which is overriding your web.xml. Add these line at the end and delete the other datasource you declared in it before (don’t touch your web.xml). It must be placed in the same folder as the jetty-env.xml.

Now you should try building your program. Of course modify your java code to connect to the jetty container and not the tomcat you were using before. That should do the trick. Note that you can’t deploy your application by typing “mvn jetty:deploy-war” because the configuration we made are applicable only for a certain phase. So your datasource won’t be declared, you will have the default port too.

I hope you enjoy.

Configuration of the Selenium Plugin

Hi there,

I’m back to help you configure your pom.xml and make it work fine with your webapplication ! So if you followed before we have splitted our server side tests and our client side tests (**/Selenium*.java), now we need to use Selenium RC to execute some tests. 

Step 1 : Selenium IDE and scLocators

First of all you should go on the smartClient website and download the custom user-extensions they provide us. It is right here : smartGWT Downloads

Then download the Selenium IDE firefox plugin and start it. All the instructions you need are in the selenium folder of the smartGWT zip that you downloaded right before. (Adding the custom user-extensions.js and core to the Selenium IDE, everything is explained right) This is necessary because without that extension, you will not be able to get fixed ID. Also ensure that your elements all have a setID(string id) property set correctly so that you can find them more easily.

After you made that just make friends with your new unit testing application, try to create some tests. Once you’ve write a test that fits your needs, just export it as Java-JUnit 4-Selenium RC so that you can use it in your Java program. Now you have your first test. Of course it won’t work. Ensure this test is placed in the test folder of your application, and has a name that fits the pattern we defined earlier.

Step 2 : The Maven Selenium Plugin

Once you have made that, you should add the maven selenium plugin in your pom.xml. It’s quite easy once you know what to add and how to add it.

Here are some explanations about the configuration :

  • You’ll have to add this : <selenium-maven-plugin.version>2.3</selenium-maven-plugin.version> in the properties of your pom (and ensure it’s the latest version)
  • The <defaultUserExtensionsEnabled> is there to say “We use the default user extensions” (don’t worry it’s normal)
  • Then we define the <userExtensions> which will be added to the default user extensions. That’s magic. (don’t place it in your target folder, I recommend placing it in your test/resources folder)
  • I modified my port for the Selenium server because it was already used on the Jenkins.
  • During the pre-integration-test phase we start the server in background so it won’t block the execution of the tests.
  • During the post-integration-test phase we close the server.

Note that if you make a mistake and your Selenium server don’t want to stop, open another terminal and type “mvn selenium:stop-server”.

Step 3 : Deploy and test

Now you have your test made with selenium IDE, imported in Eclipse (or Netbeans or whatever) in the test scope, and your selenium server starting and closing each time you build. Problem : your application must be deployed for the unit tests to work. That’s a problem. That’s why we are going to see the jetty-maven-plugin in the next chapter.

Next chapter : Jetty.

scLocator and Webdriver ?


One of the main problem with Webdriver is that it doesn’t recognize scLocators. It’s a pain to find an element using xPath or DOM. As you know the implementation of scLocators are made in the user-extensions.js and Webdriver doesn’t accept that kind of file. So someone decided to make it work directly in Java. I’ll give you the code after I explained you why it would be a bad idea to use it unless you’re sure of what you’re doing.

Once your scLocators are working, there may be (must be) plenty other functionality that may not work without the user-extensions.js. Though it could be used to test other things that are not integrant parts of the smartGWT framework. So here is the code you should use if you want to implement scLocators even if I don’t recommend it, some may find it usefull.

Here you go : scLocator Java

Hope you enjoy.

Informations about Unit Testing a SmartGWT application.

Here are some useful facts that I found all over the web and that you may need. I’m assuming you’re on a continuous integration platform such as Jenkins and you use a code analysis tool like Sonar because some of the problems may happen when you try to build on the Jenkins.

  • Don’t try to use Selenium Webdriver, it’s not compatible with the custom user-extensions.js provided by smartClient.
  • Sonar doesn’t display your code coverage ? It’s normal, you need the jacoco agent to calculate the coverage of selenium tests. (It must be installed on the Sonar and in your pom.xml, I’ll give you the configuration later)
  • Do not hesitate to change the ports of the Selenium Server, it may cause the build failure of your application if that port is already used by another application. (You’ll have to modify the java code of your tests too)
  • You’ll surely find a framework named gwt-test-utils on internet. That sounds great but it’s highly not compatible with smartGWT. So don’t use it.
  • Don’t hesitate to create a profile in your pom.xml to run your tests independently of your build.

I hope you won’t fall in these traps as I did.