Grouping DataPoints in Junit 4.12

Theories is one of my most used features of JUnit. It is very useful for writing tests for behaviour with a wide range of parameters. JUnit 4.12 introduces named data points. This is useful grouping the data points in the tests. For example, you can use it to group formats for date and time separately like this:

@DataPoint("date")
public static final String SEPARATED_DATE = "yyyy-mm-dd";

@DataPoint("date")
public static final String UNSEPARATED_DATE = "yyyymmdd";

@DataPoint("time")
public static final String SEPARATED_TIME = "hh:mm:ss";

@DataPoint("time")
public static final String UNSEPARATED_TIME = "hhmmss";

@Theory
public void test(@FromDataPoints("date") String dateFormat, 
  @FromDataPoints("time") String timeFormat) {

  ...
}

The runner will pass the values SEPARATED_DATE and UNSEPARATED_DATE as the dateFormat parameter and SEPARATED_TIME and UNSEPARATED_TIME as the timeFormat parameter. No more needing to wrap the parameters in some kind of object or having to test the parameters inside the tests! Furthermore, the runner will also automatically generate all possible values for enumerations and boolean values, so you no longer need to define them as data points.

Advertisements

Mocking Java classes in Groovy vs Mockito

While experimenting with using an ODF parser in Groovy, I was attempting to write unit tests in Groovy and mocking objects from the ODF parser library was required in my tests. Prior to this, most of experience in writing unit test was in Java and mocking using Mockito. Since I had been working in Groovy, I decided to see what support Groovy provides for mocking and how it compares to Mockito (the documentation for mocking in Groovy is available on the Groovy Mocks page).

Read more of this post

[Junit] Including the parameters in the names of parameterized tests

Junit 4.11 has added the ability to include the name of the parameters in a Parameterized test. This is done by providing a String to the name argument of the @Parameters annotation. Here is an example of a test that uses this feature:

@RunWith(Parameterized.class)
public class AdditionTest 
{
    @Parameters(name="{0} + {1}")
    public static Collection<Object[]> parameters() {
        Object[][] data = new Object[][] {{1, 2, 3}, {0, 3, 3}, {-1, 1, 0}};
        return Arrays.asList(data);
    }
    
    private final int first;
    
    private final int second;
    
    private final int expected;
    
    public AdditionTest(int first, int second, int expected) {
        this.first = first;
        this.second = second;
        this.expected = expected;
    }
    
    @Test
    public void testAddition() {
        Assert.assertThat(first + second, CoreMatchers.is(expected));
    }
}

The arguments are substitued into the numeric arguments of message. In the above example, the tests would be named “testAddition[1 + 2]“, “testAddition[0 + 3]” and “testAddition[-1 + 1]“. Using this feature, you would be able to tell what the parameters were without having to refer back to your unit test code.

Prior to 4.11 the tests would have been named “testAddition[0]“, “testAddition[1]” and “testAddition[2]“, where the 0, 1 and 2 correspond to the index in the Collection that was provided as the parameters – you have to refer back to your unit test code to figure out what the parameters were. If you do NOT specify the name in 4.11, the tests will also be named in this fasion.

[Java] Setting the Window Title Font with the Substance Look and Feel

Fonts for various aspects of the UI is usually by putting the font as a default property in UIManager or UIDefaults. However, there doesn’t seem to be one for the window title. If you were using the Substance look and feel, SubstanceLookAndFeel provides the setFontPolicy(FontPolicy fontPolicy) method. By controlling FontPolicy, you will be able to control the font used for the window title.
Read more of this post

[Java] Specifying the column widths of a JTable as percentages

The widths of the columns of a JTable are specified through TableColumn.setWidth. To set the widths of the columns as percentage, set the widths of column in proportion to each other. For example:

Read more of this post

[Java] Getting Combo Box Renderers to Look Consistent with Other Combo Boxes

One way of controlling the text in a JComboBox is to provide a custom ListCellRenderer. I have seen implementations that subclass a concrete implementation (such as DefaultListCellRenderer or the BasicComboBoxRenderer). Generally though, I find that the combo boxes using such renderers can appear inconsistent with another combo box that may not have a renderer set or one that extends a different implementation. To illustrate the inconsistency that could happen, I prepared a small test program that you can download from my Github repository. It displays a number of combo boxes that are based on different renderers. Just running it produces the following dialog in Windows 7:

Read more of this post

[Java] Swing Preview Popups

Sometimes in a JTabbedPane, it is nice to show a preview of the contents of tab in the background. This is similar to the windows preview that is available in a number of modern desktop environemnts (such as Windows and Gnome with Compiz). However, the preview popup is not a standard feature in Swing. Here, we look at how this feature may be added to the JTabbedPane.
Read more of this post