3

Not sure if this will be considered a "legitimate question" or "purely opinion based", but is there a "best practice" with regards to directly testing a repository in a Spring Boot application? Or, should any integration testing simply target the associated service?

The reasoning for the question is simply the fact that, for the most part, a repository in a Spring Boot application contains no project-generated code. At best, it contains project-defined method signatures which Spring generates implementations for (assuming correct naming conventions).

Thanks...

SoCal
  • 801
  • 1
  • 10
  • 23
  • Repository is a stereotype. Is a spring compoent as Component or Service annotated classes. Do you mean JpaRepository or CrudRepository? – rick Feb 26 '19 at 16:18
  • Why would you test a Repository as you didn't write the code on your own? I assume you inherits from JpaRepository or CrudRepository. – Ctorres Feb 26 '19 at 16:44
  • Inheriting from CrudRepository interface. The "didn't write code" (other than to declare new method signatures) is the reason I am questioning the value/need of writing any JUnit tests against the repository. Seems like this can be deferred to an integration test on the service implementation, which uses the repository. But, I wanted to get input as I'm new to Spring. – SoCal Feb 26 '19 at 18:18

3 Answers3

5

If you can mess it up, you should test it. Here the opportunities to mess up can include:

  • Custom Queries (using @Query) might be wrong (there can be all kinds of logic mistakes or typos writing a query with no compile-time checking)
  • Repository methods where the query is derived from the method name might not be what you intended.
  • Arguments passed in, the type on the parameter list might not match the type needed in the query (nothing enforces this at compile time).

In all these cases you're not testing Spring Data JPA, you're testing the functionality you are implementing using Spring Data JPA.

Cases of using provided methods out of the box, like findOne, findAll, save, etc., where your fingerprints are not on it, don't need testing.

It's easy to test this stuff, and better to find the bugs earlier than later.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
  • Okay, this makes sense to me...test, but only those things that are declared in the repository interface at the local project level. I might add that it seems prudent to include tests for expected error conditions, even on out-of-the-box Spring Data JPA methods (e.g., constraint errors on add/update, etc.). Grazi... – SoCal Feb 26 '19 at 20:40
0

Yes, I think is a good pratice to do that. You could use @DataJpaTest annotation, it starts a in memory database. The official documentation says:

You can use the @DataJpaTest annotation to test JPA applications. By default, it configures an in-memory embedded database, scans for @Entity classes, and configures Spring Data JPA repositories. Regular @Component beans are not loaded into the ApplicationContext.

Link to the docs: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html

Leandro Rosa
  • 96
  • 4
  • 1
    I understand "how" to test the repository. The question I have is "why is it a good practice?" – SoCal Feb 26 '19 at 18:20
0

Starting from the idea that repositories should be used only inside services and services are used to interact with the other layers of the system, I would say that testing services should be enough in the majority of cases.

I would not test standard repository methods like findAll, or findBy.., they were tested already and the purpose is not to test JPA, but rather the application.

The only repository methods that should have direct tests are the ones with custom queries. These queries may be located in a shared library and it is not efficient to write similar tests across different projects(in this case regression is a big concern)

Adina Rolea
  • 2,031
  • 1
  • 7
  • 16