Softwire Blog


Find out the java testing libraries that will make your life easier


22 August 2014, by

Unit testing is generally considered a good thing, but a worker is only as good as their tools. The tools that immediately spring to mind when writing java unit tests are JUnit, and HamCrest. But are these the best tools for the job? This post explores a couple of alternatives. Depending on the task you are trying achieve, these may be better or worse alternatives, but it’s always good to know your options.

JarSpec

This library is a neat way of writing more descriptive unit tests. It was created by Softwire’s Harry Cummings as a solution which enables Java unit tests to be coded in a manner similar to RSpec:

@RunWith(JarSpecJUnitRunner.class)
public class MinimalSpec implements Specification {
  @Override
  public SpecificationNode root() {
    return describe("addition", () ->
      describe("of 1+1", () -> {
        int result = 1 + 1;
        return by(
          it("should equal 2", () -> assertEquals(2, result)),
          it("should equal 3", () -> assertEquals(3, result))
        );
      })
    );
  }
}

The code to JarSpec is on GitHub.

AssertJ

AssertJ is a matcher library that is set up to allow good integration with IDEs.
Rather than typing:

assertContains(list, value)

which could match several different types other that List, you type:

assertThat(list).contains(value)

Not only is this nicer to read, after typing the period, your IDE can immediately suggest all of the assertions that can be performed on the list. When trying to do code completion in the first example, you have to pick your method from all of the assertions that exist.

The code to AssertJ is on GitHub.

Getting FAT – Becoming Fanatical About Testing at Softwire


26 November 2013, by

What are Guilds?

At Softwire, we’re always keen to learn from others, but it can be difficult to apply lessons from elsewhere in the software industry that we come across at conferences, in literature and online; because much of the wisdom on best practices in our field seems to be aimed at product companies or in-house enterprise development teams. As a services company, we have a very different structure and different commercial pressures.

However, sometimes lessons from other companies really resonate with us. One example of this was the article on Scaling Agile at Spotify, which Camille posted to our internal blog. Much of it seemed relevant to us, especially as we’d grown in the last few years from a small business to a medium-sized one, while trying to retain for ourselves the benefits of working in a small company environment.

There are a lot of great ideas in Spotify’s structure, but the concept of guilds stood out particularly. Guilds are described in the above article as “… a more organic and wide-reaching ‘community of interest’, a group of people that want to share knowledge, tools, code, and practices”. Something about the idea of a guild as a group of particularly enthusiastic people also reminded us of a phrase in Kevlin Henney’s keynote at DevWeek earlier this year: “we are fanatics for testing” – this struck a chord with us at Softwire!
(more…)

Testing and JavaScript: Test Frameworks


8 November 2012, by

JavaScript is something that turns up pretty much everywhere, and it can be a tricky beastie; there’s no static typing, a long enough list of gotchas to let you hang yourself, and by and large it doesn’t leave you with much in the way of useful logs and stacktraces to help save the day. This makes testing important!

Unfortunately, that’s easier said than done. JavaScript code is very easy to write in a way that’s not very testable, and it just doesn’t have as much of a testing culture around it as say, Java. It means there’s not so much of a consensus on tools, and it’s somewhat difficult finding sensible ones for standard testing practices. Fortunately, I’ve made some lists! This is the first in a three part series: test frameworks.

(more…)

Code coverage: the unattainable 100%


27 August 2012, by

This probably feeds into Rowan’s recent series of blog posts, but rather than looking into the mechanics of writing unit tests, I’m going to discuss a little about the logistics of applying them, and how you can ensure that your tests are actually useful.

From my early days as a cynic, I’ve come full circle and am now a great fan of unit tests. Sometimes I even prefer writing them instead of “real” code. At times I have a tendency to write somewhat esoteric code, and a comprehensive unit test suite is one way to ensure that the customer has as much confidence in the code as I do – and the best way to make sure that you have a comprehensive unit test suite is to measure code coverage. That, however, is not without some pitfalls…

(more…)

Unit testing NHibernate-based data access code using SQLite


30 January 2012, by

Code that interacts with a database, either directly or through an Object-Relational Mapping (ORM) library like NHibernate, is often quite difficult to test. This blog post looks at unit testing data access code using FluentNHibernate mappings, but it should apply just as well to vanilla NHibernate and other ORMs.

NHibernate provides interfaces for everything, which you theoretically could use to provide mocks to your code under test, but mocking complex 3rd-party library classes like this is not necessarily a good idea: you’d need to know exactly how your code was using the NHibernate API in order to do so. It’s best to think of NHibernate as part of your standard library and provide a real NHibernate session to your code under test.

The problem with this is that a real NHibernate session needs a real database. If you want to test with the same DB as your production code, this means keeping a database server running for your test, getting data into it, working out how to cope with multiple tests using the same database, etc… the resulting test runs are going to be slow and a lot of work to maintain.

Enter SQLite. It’s a single-DLL relational database management system (RDBMS) that can create a database from scratch for each test (so no worrying about setting up fixtures for tests running in parallel), in a single file on disk or in memory (the latter of which is *fast*). Using SQLite for unit tests is nothing new, but there are a lot of configuration options to consider, and I thought it would be worth documenting the end result that we arrived at when doing this sort of testing on our previous project.

(more…)