A canonical Repository test

There are only so many ways to test that your persistence layer is implemented correctly or that you’re using an ORM correctly. Here’s my canonical tests for a repository (Java-version):

Very simple. The samplePerson test helper generates actually random people:

If your data has relationships with other entities, you may want to include those as well:

A simple and easy way to simplify your Repository testing.

(The tests use FEST assert 2 for the syntax. Look at FluentAssertions for a similar API in .NET)

(Yes, this is what some people would call an integration test. Personally, I can’t be bothered with this sort of classifications)

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Code, English, Extreme Programming, Java, Unit testing. Bookmark the permalink.

5 Responses to A canonical Repository test

  1. 1) Shouldn’t the test name be “shouldFindByName”? (“By” instead of “B”)

    2) I am confued by setting the name to “A. Matching Person” but using “MATCH” in
    repository.findByNameLike(“MATCH”). I suppose that Like is case-insensitive substring match –
    I would prefere to have these two properties (substring, insensitive) mentioned either in the test’s name
    or at least in a comment. But perhaps in your team the meaning of Like is clear so this info isn’t needed.

    BTW, I could not log-in with Twitter using FF, it just opens this blog in a new window. Ok in Chrome.

  2. Thanks for the comment, Jakub. I’ve changed the name to shouldFindByCaseInsensitiveSubstringOfName

  3. Pingback: Most interesting links of April ’13 « The Holy Java

  4. Kasun Chaturanga Gajamange says:

    With the TDD we need to construct our code (or the solution ) with the series of tests. But if the application environment is heavy ( If applications loads hundreds of hibernate entities at the start-up) , I feel this tests makes some slowness on the coding. Am i right ? I felt this with a legacy application.. What are the practices to overcome this kind situations ..

  5. Hi Kasun
    It was good to see you at the coding dojo tonight

    The most important goal is to find a way to test the application without the slower parts like Hibernate. This can either be by faking/mocking the repository layer in most other tests, or by avoiding slow tech like Hibernate altogether. The latter is of course not always an option.

    When mocking/faking the Repositories, you still need a set of test to run the cover the actual repository information (that’s the kind of tests I list here).

Comments are closed.