Here are some more notes and various pointers on software engineering quality, continuous delivery and dev-qa-ops practices gathered during devoxxfr, after buid-promotion, this entry will be about tests and code analysis
Here is TDD friendly plugin http://moreunit.sourceforge.net/ It’s for eclipse, but it looks like there is one for intelliJ too cf. http://rjohnshields.com/blog/?p=89
Once you have your tests done, you can run them continously within your IDE with http://infinitest.org
that will run all impacted tests after each code change.
FEST-Assert is a set of libraries and fixture to make your assertions more readable: http://fest.easytesting.org/
We had refresher on PageObject and PageFactory pattern with selenium with Florent^. 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 (AmazonSearchResultsPage) 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.
cf.
Florent also demoed and mentioned Headless Functional Testing with Selenium and PhantomJS:
Note that you can also write smart and readable assertion with FluentLenium, this framework lets you use the assertion framework you like, either jUnit assertions, Hamcrest or Fest-assert.cf. https://github.com/FluentLenium/FluentLenium
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. http://massol.myxwiki.org/xwiki/bin/view/Blog/Devoxx+France+2013
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
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.
Romain gave a fun and refreshing quickie on PMD and more especially PMD for javascript.
If you start using it,
start small with your own small subset agreed and understood by the entire dev team. Add it to ``your definition of done''
enable that within the IDE through plugins cf. http://pmd.sourceforge.net/pmd-5.0.3/integrations.html http://plugins.jetbrains.com/plugin/?id=1137 http://pmd.sourceforge.net/eclipse/
You’ll find more on this through the presentations Romain and I did a few years back see http://www.touilleur-express.fr/2009/09/18/compte-rendu-de-la-soiree-qualite-du-logiciel-au-paris-jug-le-15-septembre-2009/ and http://www.jroller.com/francoisledroff/entry/tous_mes_voeux_pour_une
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. http://maven.apache.org/enforcer/enforcer-rules/index.html
Are you also willing to visualize to better analyze your dependencies: ispace could be a tool for you:http://ispace.stribor.de/index.php?n=Ispace.Screenshots[http://ispace.stribor.de/index.php?n=Ispace.Screenshots]
Sonar does provide a nice dependency matrix too:http://docs.codehaus.org/display/SONAR/Cycles+-Dependency+Structure+Matrix[http://docs.codehaus.org/display/SONAR/Cycles-+Dependency+Structure+Matrix]
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.