Here are some more notes and various pointers on software engineering quality, continuous delivery and dev-qa-ops practices gathered during devoxxfrimage, after buid-promotionimage, this entry will be about tests and code analysis


link:[]IDE tools

link:[]Unit testing

link:[]Functional testing

We had refresher on PageObjectimage and PageFactoryimage pattern with selenium with Florent^image. These patterns allow to dissociate the DOM from the functional testing.

  • A page object is an object-oriented class that serves as an interface to a page of your Application Under Test. The tests then use the methods of this page object class whenever they need to interact with that page of the UI. The benefit is that if the UI changes for the page, the tests themselves don’t need to change, only the code within the page object needs to change. Subsequently all changes to support that new UI are located in one place.

  • The page factory instantiates our page object (AmazonSearchResultsPageimage) and finds the annotated fields. The returned search results page is then a fully populated page object, ready to be used by the test as before.


Florent also demoed and mentioned Headless Functional Testing with Selenium and PhantomJSimage:

Note that you can also write smart and readable assertion with FluentLeniumimage, this framework lets you use the assertion framework you like, either jUnit assertions, Hamcrest or

link:[]Performance testing

  • JMeter is getting old, but is still useful

  • I also met with Stéphaneimage during the ``les mercenaires du devops'' session.
    I had a quick demo of Gatlin. Gatlinimage is definitely something I need to try out.

link:[]Test Coverage

Having a good test coverage is wishfull thinking, but what about failing the build is the coverage is not meeting the team’s definition of done, again, a maven plugin is here to help:

Vincent gave a few tips on this in his talk cf.

  • Put the Jacoco check in ``Quality'' Maven Profile

  • Have a CI job to execute that profile regularly

    • Expect about 15% overhead compared to build without checks

link:[]Code Analysis

a name=``BackfromDevoxx-Part3-Dev-QA-OpsThoughts-AboutTestsandCodeanalysis-APIstability''>API stability

Vincent also brought us back to this old but still usefull utilities: clirr. What is Clirr ?

Basically you give it two sets of JAR files and Clirr dumps out a list of changes in the public API. Clirr Maven Plugin can be used to break the build if it detects incompatible API changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary or source compatibility problems.

Vincent also mentioned a plugin unknown to me before: maven-duplicate-finder-plugin

this will search for classes with the same name, as well as resources with the same path, in the classpaths of a maven project.


Romainimage gave a fun and refreshing quickie on PMD and more especially PMD for javascript.
If you start using it,

link:[]dependencies management

Another interesting maven related input: any project may face dependency version issue, through maven transitive dependencies, one way around this

The above will make ensure that every (transitive) dependency is resolved to it’s specified version or higher, but there are more rules, you can also ensure that all dependencies converge to the same version cf.

Are you also willing to visualize to better analyze your dependencies: ispace could be a tool for you:[]

Sonar does provide a nice dependency matrix too:[]

link:[]Quality dashboard

Lost of devoxx speakers agreed that in sonar what counts are not really numbers but the history, the trends.

Did you know you can enable code reviews within sonar ? yes we can cf.

Remember the ultimate goal is not to blame individuals but to

  • improve the overall quality and maintainability of your projects

  • assess and manage its technical debt.