Who’s been fetching from my repo? is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Let’s start with a short version of this retrospective. Last year was made of:

• 8 releases of Sonar
• 110+ releases in the ecosystem
• 55,000 downloads of Sonar
• 10,000+ messages on mailing lists

So I suppose we can call this a pretty active year for the community. Now, the longer version:

The Plan

One year ago, we had the following ambitions :

Track changes : The next step is to provide the ability to report on code coverage of new source code. This is to ensure that whatever legacy code is there, teams have the ability to monitor the coverage by unit tests on added code if they wish.

Since Sonar 2.7 and with help of the SCM Activity plugin, this magic feature is available.

Code Review : This is really the next strategic move for the Sonar platform : add a manual dimension to the automated one to provide a complete code review tool.

This was a major change to accomodate into the platform and we therefore decided to adopt a baby step approach. The full functionality was delivered over 5 releases, from 2.8 to 2.12. Here is what the platform now covers:

• Review a violation
• Comment, assign, plan a review
• Flag false-positive violations through the UI
• Create manual violations through the UI
• Change the severity of a violation through the UI

Next step will be to provide the ability to customize the review workflow and its related permissions.

Language consolidation : Provide a Squid-like engine to the C# plugin to make it more robust

It took us 6 month with the great help of Alexandre Victoor to rewrite the C# plugin that embeds its own C# parser and natively supports visual studio projects.

Language consolidation : Improve the C parser to gain robustness, support non ANSI-85 extensions and increase significantly the number of rules available

We haven’t worked as much as we wanted on this C plugin and so the number of rules remains limited. That’s why we’ve already started working to implement the MISRA-C standard.

Language consolidation : Improve the PL/SQL plugin to provide currently missing metrics

A PL/SQL parser has been written to provide all those metrics and to start implementing some new rules outside the Toad CodeXpert tool.

Sonar Eclipse : Now that we have a stable version 1.0 of the plugin, we can start building on it. The objective for this year is to provide capability for running local analysis inside Eclipse

This local mode is now available but in fact the greatest new feature of Sonar Eclipse is certainly the integration of Mylyn to manage reviews directly from the IDE.

Support New Bootstrappers : We have started last year some background work to decouple Sonar from Maven. This work will enable us to support 2 new mechanisms for bootstrapping analysis in Sonar 2.6 : an ANT task and a Java runner. Next step is to also provide Gradle bootstrapper.

DONE, DONE, DONE, Sonar is now fully decoupled from Maven but if you want to use the power of Maven along with Sonar, it is of course still possible.

JaCoCo Integration : We intend to make 2 major integrations of JaCoCo into Sonar this year. The first one is to integrate it into Sonar core. The second one is to provide ANT integration of JaCoCo and therefore provide a simple way of gathering code coverage when you execute unit tests from ANT.

DONE & DONE.

Beyond the Plan

Obviously, we did not plan for all upcoming innovations for the year. Here are three major features of Sonar that weren’t planned and that have been implemented:

• Sonar CPD : this new technology introduced in Sonar 2.10 will fully replace PMD CPD in Sonar 2.14 and allows to track cross-projects duplications
• i18n : Since Sonar 2.10 the Sonar UI can be in spanish, french, greek…
• Email notifications : Since Sonar 2.10 a user can subscribe to some events to be notified by email. For instance when a review is assigned to him.

And this is also true in the ecosystem, here are two examples:

• a great effort made on the PHP plugin to resurrect it
• development of an extension for SAP ABAP

So after all this, what could be an exciting challenge for 2012 ? This is going to be the subject of my next post !

Comic: Configuration Management is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Lost in Translation

First off, let this be a warning to any potential FOSDEM-goers. ULB, the University that hosts the event, has two campuses. Campus Solbosch, where the entirety of FOSDEM happens, and about 11km from that, way over on the other side of the city, Campus Erasmus, where I went. Top tip: when planning international trips to foreign countries that you’ve never visited before, don’t rely on Google Maps.

After a 1hr 30min commute, with the help of a few fellow location-impaired, and thankfully French-and-English-speaking FOSDEM attendees, I finally made it to Campus Solbosch. Unfortunately that meant missing the welcome keynote, the introduction to the Free Java Dev Room, and talks about the OpenJDK from Mark Reinhold and Dalibor Topic. Massive facepalm. Hugely embarrassing. Mothers, don’t let your children grow up to be… someone who goes to the wrong ULB campus for FOSDEM.

Lambdas and Traits and Bears, Oh My

The first talk I saw was by Jeroen Frijters, demonstrating the work he’s been doing to bring JSR292 (Invoke Dynamic) to IKVM.NET, the virtual machine that runs Java on the CLR. Next up came Remi Forax to discuss lambdas in Java. Following a clear disclaimer that design choices and syntax he discussed was still in the air, and subject to change, he showed off an expected feature for the Java language. Named “Virtual Extension Methods", they allow adding methods to interfaces… with implementations. The motivation being that, along with lambdas, you could put a method like Iterable<T> filter(Predicate<T> predicate) onto, say, java.lang.Iterable, with an implementation, without causing compiler errors in everyone’s code. There was a bit of a collective gasp when some people in the audience assumed this meant multiple inheritance was coming to Java. However, the subtle but crucial point is that with a virtual extension method, it’s not possible to reference state, such as fields. The body of a virtual extension method must rely on the concrete implementations to supply state, with the developer resolving conflicts from inherited methods in the concrete implementation at compile time. That leaves the feature looking a lot more like traits (awesome) than C++ style multiple inheritance with the diamond problem (not awesome).

Following Remi were Raoul Gabriel Urma and Janina Voigt, two PhD students from Cambridge, who used the OpenJDK to explore the use of covariant arrays in the wild. Taking a look at lots of open-source projects, and using the novel approach of modifying the javac compiler to find the code they were interested in, they found that covariance is rarely required, and normal Java generics is usually enough to add type safety to methods employing covariance. I really liked the empirical approach taken to a language theory question, and love the idea they had of setting up some kind of open-source corpus, where those doing similar surveys could quickly get their hands on a huge amount of real-world code.

Community Is Not Just A TV Show

Then came Ben Evans and Martijn Verburg, giving a talk entitled “Politics, Positives, Paperwork and Pain: Our year to date in the JCP". Ben and Martijn are the leaders of the London Java user group, the London Java Community (LJC), which, in the past year, has won a voting seat on the JCP (Java Community Process). They discussed some of their experiences, from the bad:

- the acronym soup that appear in most every conversation (JCP, JSR, JSPA, TCK, RI… TLA ETC - okay those last two aren’t real)
- phone conference calls with lawyers representing some of the companies involved in the JCP, discussing in minute detail whether to change “notwithstanding” to “nevertheless” in clause 27(g)
- no-show members of the JCP who only participate in discussions after decisions they don’t like have already been made

But they did have a lot of positives to recount:

- completion of the first of several reforms to the JSR (Java Specification Request) process which will make it more open and inclusive, and hopefully “prevent another EJB 2″
- the (surprising) willingness and motivation of several of the bigger JCP members to move towards being more open
- significant takeup of the LJC-led “Adopt a JSR” appeal, which gets everyday developers involved in particular JSRs, from development to evangelism (I myself am signed up to take part in JSR 353 - API for JSON Processing, as we have been building a JSON-based API for one of our products recently)
- drumming up lots of interest in contributing to the OpenJDK from LJC developers, which included a couple of ‘Warnings Cleanup’ hack sessions, where a bunch of hackers dived into the OpenJDK code to pick some low hanging fruit, fix the code, and submit patches. This is slowly pushing the OpenJDK project to make building, modifying and contributing much easier. One such event was hosted here at TIM Group, with all available spaces being taken about an hour after announcing it on meetup.com.

Overall Ben and Martijn are optimistic about the future of the OpenJDK as a community.

Open Sesame

For the rest of the afternoon, we were introduced to several open-source tools: Thermostat for monitoring performance of your Java application; GCSpy for inspecting and visualising garbage collection (here was the first time I heard the humorous quote “If Java had true garbage collection, most programs would delete themselves upon execution.” – Robert Sewell); Byteman which allows you to inject bytecode into classes at runtime, and a DSL to allow you to talk about bytecode at a higher level of abstraction; and CacioWeb, which can let you run a Swing app inside your browser, which struck me as weird thing to want to do, but it had some pretty interesting use cases (e.g. rather than people using VNC to access their own Swing app running in their own JVM, the app can be hosted by a single JVM for multiple users). Steve O’ Grady argued, with some metrics and empirical counts, that Java the language is still not dead, and it’s not only about the JVM either.

The audience were also given the fine treat of listening to me harp on about they should design their classes to be immutable, and how they should totally use Mutability Detector to keep them that way, the lucky devils. It’s not every day you get to hear me crack some lame jokes about how XML sucks (my colleagues, on the other hand…). Some good ideas and suggestions came out of the Q&A after my talk, and I also got a lot of positive feedback (like Mark Reinhold tweeting “@grundlefleck’s Java immutability detector is really cool” – after which I almost audibly squee‘d). Overall Mutability Detector was received well, and I’m really glad I applied to present.

Absinthe Makes The Heart Grow Fonder

Once Saturday’s talks were finished, I was invited to dinner with other speakers and sponsors of the Free Java Dev Room in a restaurant just off Brussel’s Grand Place. Lots of interesting code talk, nice food, and Belgian beer. Having spent a lot of Saturday suffering from Friday night’s excesses at FOSDEMs Free Beer event at a local bar named Delerium, I didn’t fancy a repeat on Sunday. So I ducked out early-ish, before Raoul, the PhD student and Belgian native, could convince me to visit a nearby absinthe bar. Judging by the ‘tender’ disposition of some of the folks on Sunday morning, it appeared to be one of the more sensible choices I made over the weekend.

Fast Ruby and ARMed Java

The first Sunday talk I attended was Charles Nutter discussing JRuby and some of the achievements they’ve made with the project. I was surprised to hear that JRuby on the JVM was (for most things) the fastest implementation of Ruby around, even including native implementations. Then came a talk on how the Eclipse project works. It was interesting to see just how big an ecosystem and community it is, and they managed to ship, on time, on the same date for the past six years. The speaker, Mike Milinkovich, emphasized the importance of predictable releases, and how the Eclipse project has and will drop features to make the scheduled release date. We then heard from Andrew Haley of RedHat, the work he’d been doing to port OpenJDK to ARM processors, and someone from the audience showed an Eclipse installation which was built, and currently running, on an ARM processor machine, which was impressive.

The next talk which (I am told) was excellent, was on a music-based Java project named Gervill. It included a musical representation of a Java program, using the Byteman project demonstrated the previous day, where every call to list.add(), was translated into a note, where the index argument became a position on the scale. I say I was told it was excellent, because I’d actually ducked out of this talk, and into one of FOSDEM’s Hack Rooms, where I introduced Martijn Verburg to the internal workings of Mutability Detector, which lead to the first bit of activity ("frsit psot", and a patch!) on my project’s mailing list.

The day concluded with talks about IcedRobot (an Android implementation for the desktop), IcedTea and IcedTea-Web (RedHat’s repackaging of Oracle’s OpenJDK sans proprietary parts), and then a free-form discussion on Java, with the likes of Mark Reinhold, Dalibor Topic, Georges Raab (the VP of Software Development, Java Platform Group at Oracle) answering questions and discussing community issues in and around the OpenJDK project. It’s great to see this kind of discussion take place, and it’s somehow always astonishing to me to hear just how many people and projects depend on Java, and how much effort goes into releases, distribution and upgrades. I’m so glad that in my day job here at TIM Group, we generally only work in two week release cycles, developing a hosted web application – some of our problems can seem slightly trivial in comparison!

And thus ended the scheduled talks at FOSDEM. I capped off the weekend enjoying a few beers and dinner with a few of the speakers from the Free Java Dev Room.

Belgium, man! Belgium!

Overall, despite the calamitous beginning of the weekend, attending FOSDEM was a hugely rewarding experience. The speaker line-up for the Java room was impressive, and it looked to be the same for the other tracks and dev rooms, with well known names in the open-source world. The conference also gave me the chance to meet and personally thank Koshuke Kawaguchi for his and the rest of the project’s efforts on the Jenkins CI system that is used heavily at TIM Group. There was a very friendly vibe around the place, and what the organizers accomplish, without ever charging a penny for tickets, is astonishing.

So in summary, if you can make it to FOSDEM (and it definitely helps if you work for a company like TIM Group, that lets you take the time to go, and puts up the cash for travel and accommodation), you definitely should… but you should go to the correct campus.

Give Travis your love is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

Sonar and Gradle Multi-Module Projects
By Gunnar Hillert, 13 January 2012
I love Sonar. It is a wonderful way to collect some metrics for your Java projects – hassle-free and wrapped in a sweet-looking UI. For Maven-based projects Sonar literally works out of the box. Just start up your Sonar instance (assuming you are using the default settings running on localhost) and then you simply fire it off using:

Measuring Code
By David Green, 2 January 2012
How good is your code? If you’re like the other 80% of above average developers, then I bet your code is pretty awesome. But are you sure? How can you tell? Or perhaps you’re working on a legacy code base – just how bad is the code? And is it getting better? Code metrics provide a way of measuring your code – some people love ‘em, but some hate ‘em.

Making a Business Case For Using Codehaus Sonar
By Chris Khoo, 6 January 2012
Augmenting the development process is often a hard sell – processes don’t contribute directly to company profits and there are financial and time costs (for integration and maintenance) to consider. Personally, I’m a firm believer in adopting processes on an as-needed basis rather than trying to build the ultimate workflow/process all at once.

Couverture des tests d’intégration avec JaCoCo, Maven et Sonar
By Jean-Christophe, 23 January 2012
Dans nos projets on rencontre souvent ce cas de figure : certaines portions de code se prêtent mal au test unitaire. Ce sont les interfaces graphiques, le code qui manipule des fichiers, les connexions réseaux… Cela peut poser problème lorsqu’on …

Continuous Integration and Testing
By John Dobie, 16 January 2012
How do you know if using code metrics really does help to produce code with fewer bugs.
I am convinced they do, but how can I possibly prove it? All projects have historic data. This is usually stored in your bug tracking and source code control tools. We can use the data stored in these systems to perform ‘code forensics.’ We use the historic data from real issues to see if they could have been avoided.

To me it’s important to understand the place of CM on your project, especially as the landscape is changing so rapidly.

That’s why I’m telling you about the call for papers for the conference in London, on May 29. I’d love to see some submissions from people who are addressing CM as part of DevOps (and not just system configuration management).

Link.

BCS Configuration Management 2012 Conference – Call for Papers is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

• Accurev just attempted to make a corporate version of git. I think most of the enhancements that they’ve added will horrify the typical git user, but that’s not to say that development managers won’t buy it by the bucketload to stop their devs moaning about Subversion. [link]
• ThoughtWorks released a new version of Mingle that makes a Kanban board. [link]
• UrbanCode [warning, they sponsor this blog] added a thoughtful feature to their tools: disabling Nagios checks while you deploy [link]
• DevOpsDays Austin is selling out fast. April 2 and 3. [link]
• Sonatype are announcing Nexus 2 features later this month. I’ll report back.

Update: Wolfplusplus pointed out that Fog Creek’s Kiln seems to be the same trick as Kando, but for Mercurial. I think the Accurev version plays more to the suits, though.

Vendor news, February 2 is a post from: The Build Doctor. Sponsored by AnthillPro, the build and deployment automation server that lets you release with confidence.

For example:

StandardFileSystemManager manager = new StandardFileSystemManager();
manager.init();
manager.resolveFile("ram://root/file.txt").createFile(); // prepare test harness
...
manager.resolveFile("ram://root/file.txt").getName(); // do something useful

Annoyingly, Apache VFS API provides a way to check if a file/folder is hidden, but, although it is always possible to manually create hidden files on your system, there is no way to mark a file as hidden in the RAM filesystem.

manager.resolveFile("ram://root/file.txt").isHidden(); // returns false
manager.resolveFile("ram://root/.file.txt").isHidden(); // also returns false

The solution is to modify the RAM filesystem and customize its checking of the hidden attribute. This means that we need a new RamFileProvider, a new RamFileSystem and finally a new RamFileObject. In this example, all files and folders whose names start with a dot will be considered hidden:

public class RamFileProvider extends org.apache.commons.vfs2.provider.ram.RamFileProvider {
  @Override
  protected FileSystem doCreateFileSystem(FileName name, FileSystemOptions fileSystemOptions) throws FileSystemException {
    return new RamFileSystem(name, fileSystemOptions);
  }

  private static class RamFileSystem extends org.apache.commons.vfs2.provider.ram.RamFileSystem {
    public RamFileSystem(FileName rootName, FileSystemOptions fileSystemOptions) {
      super(rootName, fileSystemOptions);
    }

    @Override
    protected FileObject createFile(AbstractFileName name) throws Exception {
      return new RamFileObject(name, this);
    }
  }

  private static class RamFileObject extends org.apache.commons.vfs2.provider.ram.RamFileObject {
    public RamFileObject(AbstractFileName name, RamFileSystem ramFileSystemWithHiddenSupport) {
      super(name, ramFileSystemWithHiddenSupport);
    }

    @Override
    public boolean isHidden() throws FileSystemException {
      // this is the important part
      if (getName().getBaseName().startsWith(".")) {
        return true;
      }
      return super.isHidden(); // in practice, this always return false
    }
  }
}

Finally, this new RamFileProvider must be registered with your existing FileSystemManager. In my case, I get something like that:

StandardFileSystemManager manager = new StandardFileSystemManager();
manager.init();
manager.addProvider("ram-ext", new RamFileProvider());
manager.resolveFile("ram-ext:///root/file.txt").createFile();
manager.resolveFile("ram-ext:///root/.file.txt").createFile();
...
manager.resolveFile("ram-ext://root/file.txt").isHidden(); // returns false
manager.resolveFile("ram-ext://root/.file.txt").isHidden(); // returns true

Note that I did not replace the “ram” filesystem entirely. Although that would have been my preferred option, that would have taken too much time in my little experiment.

Naturally, I replied with a typically long-winded answer. She must have liked it though, because she suggested I cut and paste my reply into a blog post. Here it is!

The key thing with a newbie agile team is to not say “move testers on all teams into automated testing” but “help all teams learn to take whole-team responsibility for quality and testing, and learn how programmers and testers collaborate to automate tests at all levels”. Automated test code is code, and generally, it’s much quicker and better in the long run for programmers to code the automation fixtures. Testers know what to test, and when programmers do the coding, testers have lots of time to help customers come up with examples of desired behavior to turn into tests. Then they can pair with the programmers to automate regression testing and any other types of tests (performance, load etc). Then they will still have time to do the all-important manual exploratory testing.

If they read our book Agile Testing, they will learn that they have to be patient and invest a lot of time in learning and experimenting with different test frameworks. And they should use Mike Cohn’s test automation pyramid concept to see where they’ll get the best ROI in automation. Generally, they should always start by learning how to do TDD and get traction on unit level tests. Then they can move on to API or service level tests, then GUI. But that’s not a rule, each team has to figure out what’s best for them.

I highly recommend Gojko Adzic’s Specification by Example book, and also his blog, gojko.net. Markus Gaertner has a great ATDD book coming out but it’s not published yet.

There are SO many test frameworks, drivers, tools, it’s overwhelming. Recently we had to find a way to automate GUI regression tests for our new code that uses Dojo. Our existing GUI tools aren’t able to interpret the Dojo JS properly. It was truly a team effort, though not a smooth one. Our sys admin had earlier played around with Selenium, and we thought Webdriver might work. The sys admin did a spike and proved it did work, then he and our senior architect spiked a couple of different frameworks – one homegrown, one using Geb. They demo’ed it and got everyone’s opinions. For now we are going with the Geb framework, but down the road we might decide it’s not quite right and try something else.

Anyway, that’s a long-winded answer. One good place to start getting an idea about functional test tools is the Agile Alliance Functional Test Tools group’s spreadsheet comparing various tools, at http://bit.ly/AgileTestTools. When the teams are ready to think about functional testing, they might take a look and get an idea of all the choices. It’s a good idea to stop and plan a test automation strategy.

It is really, really hard to get started with test automation. There’s a period where it’s just extra work and no reward. But eventually they’ll cross over that Hump of Pain and start reaping the benefits, eating away at their technical debt!

/**
 *
 */
@Test
public void testGetCustomerOK() {

  LOGGER.info("======= testGetCustomerOK starting...");

  try {
    CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

    // Check.
    Assert.assertNotNull("Extra not found.", targetDTO);
    Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());

  } catch (CustomerBusinessException exception) {
    LOGGER.error("CustomerBusinessException : {}",
	    exception.getCause());
    Assert.fail(exception.getMessage());
  } catch (UnavailableResourceException exception) {
    LOGGER.error("UnavailableResourceException : {}",
	    exception.getMessage());
    Assert.fail(exception.getMessage());
  } catch (UnexpectedException exception) {
    LOGGER.error("UnexpectedException : {}" +
	    exception.getMessage());
    Assert.fail(exception.getMessage());
  } catch (Exception exception) {
    LOGGER.error("CRASH : " + exception.getMessage());
    Assert.fail(exception.getMessage());
  }

  LOGGER.info("======= testGetCustomerOK done.");
}

Facing this code, the first thing I would do is remove the logs in the catch clauses, which are clearly obscuring the code the most. They do not provide actual value, since the exception message is used in Assert.fail() calls.

/**
 *
 */
@Test
public void testGetCustomerOK() {

  LOGGER.info("======= testGetCustomerOK starting...");

  try {
    CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

    // Check.
    Assert.assertNotNull("Extra not found.", targetDTO);
    Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());

  } catch (CustomerBusinessException exception) {
    Assert.fail(exception.getMessage());
  } catch (UnavailableResourceException exception) {
    Assert.fail(exception.getMessage());
  } catch (UnexpectedException exception) {
    Assert.fail(exception.getMessage());
  } catch (Exception exception) {
    Assert.fail(exception.getMessage());
  }

  LOGGER.info("======= testGetCustomerOK done.");
}

Next, the catching of exceptions and calling Assert.fail() is in fact the same work that the test runner actually does. We can let the test runner handle those cases:

/**
 *
 */
@Test
public void testGetCustomerOK() throws Exception {

  LOGGER.info("======= testGetCustomerOK starting...");

  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  // Check.
  Assert.assertNotNull("Extra not found.", targetDTO);
  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());

  LOGGER.info("======= testGetCustomerOK done.");
}

The remaining logs are actually information that can already be known from the test runner, since test results are presented by methods. My guess is that they were added to make the previous logs more readable. They can go now:

/**
 *
 */
@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  // Check.
  Assert.assertNotNull("Extra not found.", targetDTO);
  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());
}

The “check” comment serves no useful purpose. Also, there is an empty comment that obviously adds no value:

@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  Assert.assertNotNull("Extra not found.", targetDTO);
  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());
}

We are down to 6 lines of code. The first assert does a check that is also done implicitely by the following one. That seems redundant. Also, it is clearly a situation that should not happen in a normal test run. That can go:

@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  Assert.assertEquals("accountIds must be the same.", "ABC99", targetDTO.getAccountId());
}

The remaining assertion has a comment that says what the test does. In some way, there is some value in this. However, in most (all?) cases, the person seeing the error would open the test class anyway and read the code. The test comment seems redundant. At the very least, its value is far from clear. In those situations, I remove the comments:

@Test
public void testGetCustomerOK() throws Exception {
  CustomerDTO targetDTO = this.serviceImpl.getCustomer("ABC99");

  Assert.assertEquals("ABC99", targetDTO.getAccountId());
}

OK, a little inlining can now be done:

@Test
public void testGetCustomerOK() throws Exception {
  Assert.assertEquals("ABC99", this.serviceImpl.getCustomer("ABC99").getAccountId());
}

The Assert.assertEquals method can also be statically imported:

@Test
public void testGetCustomerOK() throws Exception {
  assertEquals("ABC99", this.serviceImpl.getCustomer("ABC99").getAccountId());
}

And the test could use a renaming:

@Test
public void can_obtain_a_customer_by_account_id() throws Exception {
  assertEquals("ABC99", this.serviceImpl.getCustomer("ABC99").getAccountId());
}

Hm… the “this.” clause is not really necessary:

@Test
public void can_obtain_a_customer_by_account_id() throws Exception {
  assertEquals("ABC99", serviceImpl.getCustomer("ABC99").getAccountId());
}

And… that’s it. I’m down to 4 lines of code. There might be fewer comments, but I believe the result is a lot more readable.

My two-day hands-on Specification by Example workshop is finally coming back to London. Since 2007, more than 2000 people have benefited from this training. The workshop is aimed at testers, business analysts and developers and based on my books Specification by Example and Bridging the Communication Gap. Through facilitated exercises and discussion, you will learn:

• how to extend specifications with examples to create a single source of truth for testing and development
• how to avoid functional gaps and inconsistencies in specifications and tests
• how to run specification workshops to facilitate collaboration
• good practices for designing specifications with examples and acceptance tests for agile teams
• how to create a living documentation system to facilitate change and improve your process long-term
• how other teams, from small web startups to large distributed teams in investment banks, apply specification by example in their contexts

For more information and to sign up, see the event page on EventBrite.

Sonar and JaCoCo
By Raghu, 1 December 2011
I am a fan (and regular user) of Sonar, a platform to manage code quality. The 2.12 release of Sonar, which happened yesterday, introduced a bunch of new features including Java 7 support and the availability of Jacoco into Sonar core.

Industrialiser vos projets Flex avec Hudson, Maven, Sonar, FlexPMD et FlexCPD
By Fabien Nicollet, 5 December 2011
Dans le monde Java, il existe de nombreux outils permettant de vérifier l’intégrité de votre code (tests unitaires) mais aussi pour vous assurer que la qualité de votre code est respectée. Ces outils vous permettent d’assurer la robustesse des applications que vous créez.

My Testing and Code Analysis Toolbox
By Jens Schauder, 11 December 2011
Last week we kicked of a “Testing Skill Group” at LINEAS, a group for exchanging knowledge about testing. One question that came up over and over again in various flavors was: What tools are there for testing and analyzing your code? So here is my personal answer for this, in the approximately order I tend to introduce them into projects…

Open Source & code Legacy
By Jean-Pierre FAYOLLE, 18 December 2011
There are more and more solutions of analysis of code which allow to measure the quality of your applications. Most are sold by software vendors, and we had the opportunity to verify that these solutions are expensive to buy, to implement and to use (Disposable software). In response, the last decade has seen the rise of the Open Source alternative to proprietary software.

Flex + ( Ant | Maven ) + Sonar
By Jozef Chutka, 5 December 2011
The title may sound like there are two possible ways how you can have your source code analyzed and published to sonar, but you better do not rejoice prematurely. After spending couple of hours trying to figure out how to make it work using ant I may have hit some nice articles, however sonar-ant-task seems to have major issues with sonar version 2.8. The solution is maven!