Installing Sonar in OpenShift as a DIY application

Note: this is an excerpt extracted from my talk at Red Hat Developer Day London. You can see more about the talk in my post here:

http://deors.wordpress.com/2012/10/03/developer-day/

Sonar is a popular code profiler and dashboard that excels when used along a Continuous Integration engine:

• Seamless integration with Maven.
• Leverages best-of-breed tools as Checkstyle, PMD or FindBugs.
• Configurable quality profiles.
• Re-execution of tests and test code coverage (UT, IT).
• Design Structure Matrix analysis.
• Flexible and highly customisable dashboard.
• Actions plans / peer reviews.
• Historic views / run charts.
• Can be used with Java, .Net, C/C++, Groovy, PHP,…

The Usual Suspects – Talk in Red Hat Developer Day London, Nov 1st

On Nov 1st, I will be presenting in Red Hat Developer Day London.

The tittle of my talk is: “The Usual Suspects – Creating a Cloud Development Environment with Sonar, Selenium and JMeter on OpenShift Origin“. During the session I will show how to extend the basic development environment offered by OpenShift (Git, Maven, Jenkins) and create a more powerful environment on OpenShift featuring “usual suspects” such as Sonar for continuous quality assurance, Selenium for functional testing, JMeter for performance/load testing as well as Arquillian for in-container testing. The session includes a live demo built on OpenShift Origin.

For more information about the event, full agenda and registration, visit: http://www.redhat.com/developerday/

See you there!

Edit 2012-11-01: These are the slides for the presentation. Meanwhile they are published in the conference site I have uploaded them here: The Usual Suspects – Red Hat Developer Day 2012-11-01

 

Selenium in One Minute (Video)

For some time I’ve been willing to record and upload a short video showing how Selenium works, working in a grid with several computers/browsers and an Android table as well.

For this short demo I’ve used the Spring PetClinic reference application, tweaked to work with Spring 3.0.6 and Tomcat 7.0.22.

This short video is slightly above one minute long. Hope you enjoy it!

Using Selenium to Automate Tests in Android Browser

Yes, it’s true. With Selenium you can automate UI tests for Android browsers.

Validating how a web application behaves in multiple browsers is a growing need, as users require using any browser of their choice to consume applications. Moreover, this need spans to mobile devices: applications are demanded to be ubiquituous, and so our tests should be.

To my (pleasant) surprise, it’s very easy to run automated tests in Android browsers. Selenium includes an Android driver that supports most of the Android browsers, both simulated and in physical devices.

Continue reading to know more.

Test Automation with Selenium WebDriver and Selenium Grid – part 3: Continuous Integration

In part 1 in the series (read it here) I discussed about Selenium, the widely used tool for browser test automation, and I showed how easy is to setup a testing grid with multiple OS and browsers. In part 2 (read it here) I showed how to leverage WebDriver API to create and execute tests distributed across the grid that was created.

Now in part 3 I will show how to execute Selenium tests under a Continuous Integration process with Maven, Cargo and Jenkins, and how to gather code coverage metrics for those tests using Sonar and JaCoCo.

Test Automation with Selenium WebDriver and Selenium Grid – part 2: Creating and Executing Tests

In part 1 in the series (read it here) I presented Selenium, a widely known tool for browser test automation.

Starting with Selenium 2, the most important components from the suite are Selenium WebDriver and Selenium Grid. In part 1 I showed how easy is to setup a testing grid with multiple OS and browsers. Now in part 2 I will show how to leverage WebDriver API to create and execute tests.

Test Automation with Selenium WebDriver and Selenium Grid – part 1: Setting Up the Grid

For a long while I’ve been “dying to play” with Selenium (www.seleniumhq.org and code.google.com/p/selenium/). I’ve heard and read very good things about this tool from colleagues and from the blogosphere.

Selenium is, in short, an open source tool to automate web browser interactions. A primary use case is, of course, browser test automation.

Selenium has greatly evolved with time, specially since the 2.0 release when the legacy Selenium project merged with Google’s WebDriver. Nowadays, Selenium offers a wide range of programming languages supported to write the tests, an impressive browser compatibility list, the ability to record tests from user interactions and, above it all in my opinion, the ability to re-execute tests across a grid of machines with various operating systems, browser families and versions.

Although Selenium seems to be primarily chosen for functional/regression test automation, it’s also a great choice – precisely because of the grid feature – for cross-browser compatibility testing: ensuring in an easy, cost-effective way, that our web applications are usable in all sorts of operating systems and browsers.

In this and forthcoming posts in a short series I will share my experiences setting up a Selenium Grid, building some automated tests for a simple Spring application, re-executing them from Eclipse IDE and finally re-executing them in continuous integration (including code coverage) with Maven, Cargo, Jenkins, Sonar and JaCoCo.

Measure Code Coverage of HtmlUnit Based Tests with Sonar and JaCoCo

This blog post is the third one in a series about Integration Tests with HtmlUnit. The first post, titled “Automating Assembly and Integration Tests with HtmlUnit”, showed how to write integration tests of web UI applications using HtmlUnit. That post can be read here. The second post, titled “Integrate HtmlUnit Based Tests with Apache Maven and Cargo”, showed how to automate the execution of HtmlUnit tests using Maven and Cargo plug-in. That post can be read here.

Finally, in this post we are going to show how to measure code coverage of HtmlUnit tests using Sonar, the popular Continuous Quality Assurance tool, and JaCoCo, a very interesting code coverage tool based on JVM agents instead of instrumenting bytecodes.

Architecture Rules 3.0.0 goes RC1

Old post from Dec 11th, 2009

———————-

After some months evaluating Architecture Rules (AR for sort, web http://wiki.architecturerules.org/index.php?title=Main_Page) for serious use, and fiddling in a hate-love relationship with this tool (very good idea, not so well documented, some extrange behaviours that almost makes you resign), I found in their SVN and Maven repository that they have posted there the RC1 (release candidate) of the new 3.0.0 release.

For those that do not know about AR, this tool builds on top of JDepend to analyze the architecture, understood as module relationships and valid dependencies, of a Java project.

JDepend calculates OO metrics (Afferent, Efferent couplings, Instability, Abstractness, Distance) and also checks for circular dependencies between Java packages. JDepend is very fine, produces reports, has a fine GUI and there is an Eclipse plug-in available for your convenient use, but it is not easy to do validations in automated builds and continuous integration.

AR offers that. You can automate your architecture validation as an Ant task, Maven plug-in or, as it is most interesting to me, as a JUnit test case.

Thus, why this post? AR can be frustrating. You can easily get lost in dependencies, not found files and folders and different behaviours in unit tests if executed from Eclipse or from Maven. And this is why I would like to share some of my findings.

First, consider how to run it in an automated way. The Ant task or Maven plug-in have a disadvantage, they break the build if the architecture validation does not pass. It can be good for you but in my opinion I just want to know whether rules are being followed and continue with the rest of the build process, eventually running Sonar and publishing my results in Sonar dashboard.

So I finally decided to go for the JUnit test case. I can give you details on running in Ant and Maven but in this post from now on I will focus on JUnit and I will split the rest of the contents in these areas:

1. Dependencies.

2. Configuration.

3. Writing the test case.

4. Running.