What is the best approach for testing a MongoDB-based repository in Ktor? Should I mock responses, u...

# ktor

[Antoni Zwolski]

What is the best approach for testing a MongoDB-based repository in Ktor? Should I mock responses, use an in-memory database (if so, which library is recommended?), or simply create simple lists for testing purposes?

[Casey Brooks]

I prefer to use a fake implementation of the data stores, keeping everything just as regular lists in hand-written classes or something like that. This helps me keep the application logic from being coupled too closely to DB behavior or annotated/generated classes. This is the recommendation for Android testing as well: https://developer.android.com/training/testing/fundamentals/test-doubles

[Antoni Zwolski]

What about creating second database for testing purposes? Is it acceptable?

[Shawn]

if you're testing a DAO then you should use an in-memory database—unit tests on subjects that depend on that DAO should use a mocked DAO

[Shawn]

integration tests would also benefit from an in-memory database

[Shawn]

when you say "second database" do you mean like a second hosted database just for tests? if so, that's completely unnecessary

[Casey Brooks]

For good application architecture, your main application logic should communicate with the Repository, which does not expose any details about the underlying data store. Ideally, the classes that go in/out shouldn’t depend on anything specific to the database (for example, don’t use JDBC-annotated classes in your Repository interface). The repository’s implementation is then responsible for communicating to the database, handling errors, and formatting responses to the common models used by the rest of the application.

For testing these components, anything that depends on the Repository shouldn’t need Mongo running to complete the test. Use a fake Repository implementation here. This should be the majority of your application’s tests.

However, the Repository itself should also be tested, which does need a Mongo instance running to validate it correctly. Don’t try to use a mocking framework to mock the ORM’s APIs or create some kind of fake, because you need to validate the actual connection and behavior of your Mongo queries. This would be more like an integration test, and you shouldn’t need very many of them.

[Antoni Zwolski]

For integration tests, should I use an in-memory database? I came across Fongo, but I've read it might not be the best option as it can differ from the real MongoDB. There’s also the MongoDB In-Memory Storage Engine, but it seems to require using the enterprise version of MongoDB and might be difficult to configure. Another option I found is Testcontainers, which seem to offer the ability to test databases within Docker containers. So, I'm wondering whether it would be acceptable to just set up a dedicated MongoDB instance just for the purpose of integration testing.

[Shawn]

I'm a fan of Testcontainers myself, but it does take a little bit of work to get things working smoothly with your test runner

[Shawn]

If you're the only person you expect to ever contribute to whatever you're developing, it makes no difference

[Shawn]

but if the project ever has to be set up on another machine, then you want something portable and with minimal setup

[Antoni Zwolski]

this is just for my resume project purposes

[Shawn]

what would you rather talk about if asked about the project?

[Shawn]

how you set up an ad-hoc testing database, or how you figured out how to set up testcontainers?

[Antoni Zwolski]

This is a project for my resume, so I want it to be "good" but also not too complex. I am wondering which approach will fit my case best

[Aleksei Tirman [JB]]

You can find an example of the testing a Ktor application baked by MongoDB here.