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)

Creative Commons License
A canonical Repository test by Johannes Brodwall, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 Unported License.

About Johannes Brodwall

Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. He trains distributed teams and contributes to projects halfway across the world. He is an active contributor to the programmer community in Oslo and Sri Lanka and a veteran speaker in Norway and abroad.
This entry was posted in Code, English, Extreme Programming, Java, Unit testing. Bookmark the permalink.
  • http://twitter.com/HolyJak Jakub Holý

    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.

  • http://www.johannesbrodwall.com/ Johannes Brodwall

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

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

  • Kasun Chaturanga Gajamange

    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 ..

  • http://www.johannesbrodwall.com/ Johannes Brodwall

    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).