Verifying side effects in unit tests

[TomRHandcock]

Hello folks,

I am part of a project where we have decided to try out riverpod for state management instead of our traditional choice of bloc and so far, we are finding it great to use. I'm sure once things become more 'second nature' we'll be able to implement features quickly and concisely with riverpod offering features such as caching out of the box.

For a bit of context, our chosen architecture is to 'chain' providers to allow for abstraction of our presentation layer from our domain/service layers.

When it comes to unit testing these providers, we want to be able to assert two critical things:

1. What read operations evaluate to given a set of conditions.
2. What interactions are performed when performing a side-effect.

The first point is covered readily in the documentation however we haven't been able to identify a solution to the second point, when side effects trigger interactions with other notifiers.

In other words, if a side-effect in NotifierA triggers a side-effect in NotifierB, how does one verify this in unit tests?

@riverpod
class BookListViewmodel extends _$BookListViewmodel {
  @override
  FutureOr<List<Book>> build() async {
    return ref.watch(bookListRepositoryProvider.future);
  }

  void favoriteBook(String id) {
    // How to unit test when and how this interaction takes place?
    ref.read(bookListRepositoryProvider.notifier).setBookFavorite(id, true);
  }
}

@riverpod
class BookListRepository extends _$BookListRepository {
  @override
  FutureOr<List<Book>> build() async {
    // Fetch from persistent store.
  }

  void setBookFavorite(String id, bool favorite) {
    // Update persistent storage.
    ref.invalidateSelf();
  }
}

Many thanks in advance!

[snapsl]

For a bit of context, our chosen architecture is to 'chain' providers to allow for abstraction of our presentation layer from our domain/service layers.

Is there a particular reason for this? This looks a bit like duplication. Your repository probably does not need extra state management.

class BookListRepository {
  void setBookFavorite(String id, bool favorite) {
    // Update persistent storage.
  }
  ...
}

@riverpod
// or any other SL solution
BookListRepository bookRepo(BookRepoRef ref) => BookListRepository();

[snapsl]

Oh and regarding the testing.. You can simple verify that the function has been called and the results are as expected. (see https://codewithandrea.com/articles/unit-test-async-notifier-riverpod/)

[TomRHandcock]

Heya, thanks for the prompt response!

The main reason we are doing this is to provide separation between our presentation layer models and domain/service layer so we have more flexibility. I acknowledge my code example was misleading as it used the same models.

We did consider the option of 'providing' instances of repository classes instead of using async notifiers [like your example above], however we felt we lost some implicit benefits like reactivity and being able to share state that you get when using providers/notifiers right through the stack.

Ultimately, if there is no reasonable way to verify interactions between providers/notifiers then we may have to switch to the strategy of providing class instances so as to not sacrifice test-ability. That said, imo it does feel slightly less in the 'spirit' so-to-speak of the framework.

[snapsl]

Thank you for the explanation. 👍
Could you be more specific about what you mean by testing interactions between providers, as this should still be possible as given in the example. The only "issue" I see is that mocking a notifier can be tricky.

[TomRHandcock]

Sure thing.
What we are after is verifying method invocations in a manner similar to mockito . Ideally we would also want to be able to make assertions about the arguments those methods are invoked with and how many times the invocations took place.

To refer to my example above...
We may want a unit test that asserts, upon calling favoriteBook(<some-id>) on an instance of BookListViewmodel, it invokes setBookFavorite(<some-id>, true) on the repository. Somewhat trivial in this example but this would help catch possible future regressions.