Is it really difficult to test these "Service" methods?

help
1

I reproduced a small example of kerkour's Rust Clean Architecture on the Rust Playground.

The code is just an example and the methods code makes no sense at all.

This architecture leaks DB information to the service layer (for example methods like: find_namespace_and_membership have db: &DB argument with pub type DB = sqlx::PgPool).

This is because, quoting the author:

You may ask: Why put the db in the Service and not in the repository if it's the repository that interacts with the database?

Because we will sometimes need to call the repository's methods within transactions. So we need the repository's methods to be generics over 'normal' database operations and transactions.

I just one one question for you: Is it really difficult to test Service methods like find_namespace_and_membership without using a real DB and mocking it?

I don't know where to start, but if this is feasible I can use this architecture instead of other ones because it is much, much more practical and RAD.

I examined other architectures today (this one for example) and this is the most RAD one!

There are actually two questions, excuse me: is there something untestable / unscalable that I'm missing in this architecture right now?

2

Well, first of all you have to clear your mind and decide what exactly is what you want. As said in the quote from Kerkour's article, he decided to leak the DB type because sometimes you may need a DB engine's specific functionality like transactions. If you don't need them and instead prefer to have an abstraction that makes it easier to mock it for testing purposes, then do it so!

In other words, You can't have your cake and eat it.

3

I'm looking for a way to have an abstraction of the real DB in both the service and repository layers.

Because I can call both services and repositories with one transaction.

4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.