Category Archives: java

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 … Continue reading →

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 … Continue reading →

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 … 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 + “/” … 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 … 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.

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 … 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 … Continue reading →

Here is a typical example of a test method @Test public void should_search_by_path() { Searcher searcher = new Searcher(); Path location = new Path(“somewhere”); String data = “data”; searcher.putAt(data, location); assertThat(searcher.findAt(location), is(data)); } It seems that many developers consider this … Continue reading →