Friday, October 26, 2012

Git and Maven release:prepare

I don't know if it happens to me only due to my complex source control configuration (which uses SSH keys like Github), but it happens quite often to me that the release process gets stuck right when it's time to push changes.

When this happens you are left with almost no choice but to perform a release:rollback and start again, but today I've found a good solution to this problem: git reset.

So, if your release preparation process is interrupted for some reason and you want to restart it again, but when you try you get a message saying the git commit command failed, then just do the following:

git reset --soft HEAD~1

This command will remove the commit from your local clone leaving all the Maven changes intact, thus allowing you to recover the process where you left it.

Have fun!

Thursday, October 25, 2012

Jacoco code coverage tool

Today I discovered with great pleasure a great project for gathering unit, integration and automation tests code coverage: Jacoco!

I was so excited that I decided to give it a try on my template Maven project and the POM went down 150 lines with greatly improved readability!

No more tricky profiles or instrumented artifacts you need to include explicitly and solely to gather coverage: everything works like a charm!

Obviously my previous post regarding Cucumber tricks is still totally valid.

Thanks Jacoco!

Thursday, October 18, 2012

Gherkin syntax quicksheet

I found an interesting article containing a nicely presented and very well described Gherking syntax guide and I want to support it.

Wednesday, October 17, 2012

Embedding screenshots in Cucumber JVM

I was trying to improve our automated test suite and I thought that it could be useful to capture a screenshot of the browser whenever a test fails.
The current Cucumber JVM implementation highly simplifies this task, but the task is not achieved the way I thought, so this is the reason for this post.

Normally you would use a JUnit TestRule to augment all your test cases with a feature to take screenshots, but for Cucumber JVM it's much easier thankfully to the Execution Hooks:

 public class ScreenshotHook {  
     @Autowired  
     private WebDriver driver;
 
     @After  
     public void embedScreenshot(Scenario scenario) {  
         if (scenario.isFailed()) {  
             try {  
                 byte[] screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES);  
                 scenario.embed(screenshot, "image/png");  
             } catch (WebDriverException wde) {  
                 System.err.println(wde.getMessage());  
             } catch (ClassCastException cce) {  
                 cce.printStackTrace();  
             }  
         }  
     }  
 }  

As you can see I'm injecting the WebDriver instance (I'm using the Cucumber JVM Spring integration) and defining an embedScreenshot method which is annotated with cucumber.annotation.After: this is the important bit because methods annotated as such will be executed after each cucumber scenario.

For sake of completeness I want to tell you there is another hook cucumber.annotation.Before that can be used for things like logging into your application eliminating those repetitive log in steps.

UPDATE: Scenario was ScenarioResult in pre 1.0.0 versions of Cucumber JVM.

Tuesday, October 16, 2012

Agile and the Definition of Quality

If you are interested in software quality, if you want to improve your agile process output, if you like to have satisfied customers you want to read this article and, after reading it once, you might want to read it a second time: what he's saying is not obvious at all.

Wednesday, October 10, 2012

Selenium tests on Jenkins

It's not uncommon to have a CI server running tests based on Selenium and it's not uncommon to get in troubles with Linux headless (without a windows manager) servers.


Usually you get errors like:
Error: no display specified
or 
Error: cannot open display: :0.0

The following is what I think is a solution that should be portable and does not require a lot of configuration skills.
First of all you need to install the Jenkins Xvfb Plugin, which allows you to easily start a new virtual screen per  Jenkins job. Please do not forget to properly configure this plugin in the Jenkins System Configuration screen as described in the plugin page: if you don't know the path of the Xvfb executable you just run the following command in a shell on your CI server
 which Xvfb
Usually the value you will use as Directory in which to find the Xvfb executable is /usr/bin.

Once you have this you just need to activate the Xvfb plugin for your job and that should be it, without any modification in your POMs or any other hassle: the plugin will create a new virtual screen, set the DISPLAY environment variable and execute your build.

If you are using the FirefoxDriver, as I do, and you still have issues, but you can see in your output lines like the following ones, then your problems are not any longer related with being on a headless server and my suggestion is to ensure you are using the latest version of the selenium drivers:
Xlib:  extension "RANDR" missing on display ":32".
failed to create drawable
*** LOG addons.xpi: startup
*** LOG addons.xpi: Ignoring file entry whose name is not a valid add-on ID: /tmp/.../webdriver-staging
*** LOG addons.xpi: checkForChanges
*** LOG addons.xpi: No changes found

Please note the initial two lines are perfectly fine and not related to your issues!
I struggled with an error which actually went away right after I updated my selenium-java dependency to the current latest!