Here's how I currently am doing it: I use the repository pattern. I use a trait:

  pub trait LibraryRepository: Send + Sync + 'static {
      async fn create_supplier(
          &self,
          request: supplier::CreateRequest,
      ) -> Result<Supplier, supplier::CreateError>;

I am splitting things "vertically" (aka by feature) rather than "horizontally" (aka by layer). So "library" is a feature of my app, and "suppliers" are a concept within that feature. This call ultimately takes the information in a CreateRequest and inserts it into a database.

My implementation looks something like this:

    impl LibraryRepository for Arc<Sqlite> {
        async fn create_supplier(
            &self,
            request: supplier::CreateRequest,
        ) -> Result<Supplier, supplier::CreateError> {
            let mut tx = self
                .pool
                .begin()
                .await
                .map_err(|e| anyhow!(e).context("failed to start SQLite transaction"))?;
    
            let name = request.name().clone();
    
            let supplier = self.create_supplier(&mut tx, request).await.map_err(|e| {
                anyhow!(e).context(format!("failed to save supplier with name {name:?}"))
            })?;
    
            tx.commit()
                .await
                .map_err(|e| anyhow!(e).context("failed to commit SQLite transaction"))?;
    
            Ok(supplier)
        }

where Sqlite is

  #[derive(Debug, Clone)]
  pub struct Sqlite {
      pool: sqlx::SqlitePool,
  }

You'll notice this basically:

  1. starts a transaction
  2. delegates to an inherent method with the same name
  3. finishes the transaction

The inherent method has this signature:

  impl Sqlite {
      async fn create_supplier(
          self: &Arc<Self>,
          tx: &mut Transaction<'_, sqlx::Sqlite>,
          request: supplier::CreateRequest,
      ) -> Result<Supplier, sqlx::Error> {

So, I can choose how I want to test: with a real database, or without.

If I want to write a test using a real database, I can do so, by testing the inherent method and passing it a transaction my test harness has prepared. sqlx makes this really nice.

If I'm testing some other function, and I want to mock the database, I create a mock implementation of LibraryService, and inject it there. Won't ever interact with the database at all.

In practice, my application is 95% end-to-end tests right now because a lot of it is CRUD with little logic, but the structure means that when I've wanted to do some more fine-grained tests, it's been trivial. The tradeoff is that there's a lot of boilerplate at the moment. I'm considering trying to reduce it, but I'm okay with it right now, as it's the kind that's pretty boring: the worst thing that's happened is me copy/pasting one of these implementations of a method and forgetting to change the message in that format!. I am also not 100% sure if I like using anyhow! here, as I think I'm erasing too much of the error context. But it's working well enough for now.

I got this idea from https://www.howtocodeit.com/articles/master-hexagonal-archit..., which I am very interested to see the final part of. (and also, I find the tone pretty annoying, but the ideas are good, and it's thorough.) I'm not 100% sure that I like every aspect of this specific implementation, but it's served me pretty well so far.

Two Years of Rust