We simply create our instances from our routing classes and construct our global routes directly from them. This is good but if we want to test the routes in isolation, we still have the problem that they are hard-wired to our Repository class, which is implemented via Slick. Several options exist to handle this:

Use an in-memory test database with the according configuration.

Abstract further, and use a trait instead of the concrete repository implementation.

Write integration tests that will require a working database.

Using option 1 is tempting, but think about it some more. While the benefit is that we can use our actual implementation and will just have to fire up an in-memory database (for example h2), there are also some drawbacks:

We have to handle evolutions for the in-memory database.

Our evolutions have to be completely portable SQL. Otherwise, we’ll have to write each of our evolutions scripts two times (one for production and one for testing).

Our code has to be database agnostic. This sounds easier than it is. Even the tools we’re using may use database-specific features under the hood.

Several features are simply not implemented in some databases. Think of things like cascading deletion via foreign keys.

Taking option 2 is a valid choice but it will result in more code. We must also pay close attention to the “test repository” implementation to avoid introducing bugs there. Going for the most simple approach is usually most feasible. Think of a simple test repository implementation that will just return hard-coded values or values passed to it via a constructor.

We will go with option 3 in this case. It has the drawback that we’ll have to provide a real database environment (and maybe more) for testing. But it is as close to production as you can get. Also, we will need these either way to test our actual repository implementation, so let’s get going.