Eric Lefevre-Ardant on Java & Agile

Tests should describe a linear story, as opposed to production code. What things we start with, what we do with them, and what we get. Some call this the Given/When/Then pattern, others the Arrange/Act/Assert pattern. This means that the code should be written as a single thread that can be read with as little mental effort as possible. Although it might seem obvious in simple cases, it also means that, for example, you should avoid loops when initializing your test data:

public void can_limit_search_results_to_5()
{
    // I recommend this over a for-loop
    List list = new ArrayList();
    list.add("string");
    list.add("string");
    list.add("string");
    list.add("string");
    list.add("string");
    list.add("string"); // 6

    Store store = new Store(list);

    assertThat(store.findByName("string")).hasSize(5);
}

Similarly, avoid try/catch blocks. In older versions of JUnit, in order to check that an exception was, you had to write code like this:

public void can_fail_when_searching_on_an_invalid_name() {
    try {
        search.findByName("an invalid name");
        fail();
    }
    catch (RuntimeException e) {
        // success
    }
}

Since JUnit 4.0, this can be refactored as: @Test(expected = RuntimeException.class) public void can_limit_search_results_to_ten() { search.findByName(“an invalid name”); } This has the added benefit of producing a more explicit error message from JUnit when the test fails. What if you need to check the content of the exception message? JUnit 4 does offer a mechanism for this, but I find it rather cumbersome. I prefer the catch exception library:

public void can_fail_when_searching_on_an_invalid_name() {
    catchException(search).findByName("an invalid name");

    assertThat(caughtException()).isInstanceOf(RuntimeException.class);
    assertThat(caughtException()).hasMessage("Name is invalid");
}

If you understand French and want to hear more about the Catch Exception library, you might be interesting in this podcast episode I recently published. This is an excerpt of a chapter I’m writing for the upcoming CITCON Chronicles book.

In production code, common coding standards for Java recommend writing method names in CamelCase.

retrieveUserDetails()
createABankAccount()

This makes sense when those methods are called from our own code. It feels as if requests are being made to these objects (dear “bankTeller.createABankAccount()”, please). Besides, it follows the conventions in the Java Development Kit and with other projects, making it easy for newcomers to feel at home.

However, methods in unit tests are not called by us. They do not need to represent requests. They also have less pressure to look similar to other public APIs. They do need to tell a story, and a story is best told with space between words. We cannot put spaces in method names, but underscores come close.

should_search_by_name_address()
cannot_fail_when_address_is_not_specified()

This is an excerpt of a chapter I’m writing for the upcoming CITCON Chronicles book.

File encoding is notoriously a difficult problem for developers to fully grok. Development environments and IDEs do not always help.

I recently had a test failing under Eclipse, whereas the same test was passing fine in the command line using Maven. Here are some details on the context, and a workaround.

Continue reading →

TL;TD: Refactoring classes that have data envy is easy. Do it.

Here is a snippet extracted from the last project I worked on:

// somewhere in a class
asset.setHasAssociatedImage(!StringUtils.isBlankOrNull(imageName));
asset.setImageName(imageName);

// in another class
if (asset.hasAssociatedImage()) {
	image.setUrl(categoryName + "/" + asset.getImageName()));
} else {
	image.setUrl(categoryName + "/" + "error.gif"));
}

If you’re like me, you’ll cringe at the sight. In fact, this is a classic case of Data Envy.
Continue reading →

On the Mockito mailing list and on Stackoverflow, there are a significant number of questions that actually reveal that the person asking did not perfectly understand what the Mockito annotations do. Indeed, the annotations are rather magical and their behavior is definitely not obvious.

Since they are mostly syntactic sugar (although whether they actually improve readability is debatable), my recommendation is to do without them entirely. Here are a few examples.

Continue reading →

This post in an introduction to Fantom via the refactoring of Java code.

TL; DR: Fantom is basically a better Java with a very similar syntax, but with lots of little simplifications and some powerful features such as functions. Continue reading →

My former colleague David just posted an example of verbose test code on his blog (the parts in French have been translated to English by myself):

/**
 *
 */
@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.");
}

Let’s see what I’d do with that. Continue reading →

“Adding manpower to a late software project makes it later”. The so-called Brooks’s Law on productivity of software project is well known, since Fred Brooks’ seminal work The Mythical Man-Month, first published in 1975.

That is one of the reasons I’m wince a little when a company talks about plans to hire lots of software developers.

This recent study by QSM seems to prove me right. Its conclusion seems to be that Brooks’s Law can be extended to projects that are not late. At any rate, code is not produced at a faster pace with more manpower. Continue reading →