Scenario: the user performs an action on the screen that forces the application to load some data asynchronously and later update the view.
In my architecture, this is done as follows:
- User actions call some presenter method
- Caller's call manager that runs the asynchronous task
- Async task in background thread calls service and sends result to event bus
- When the presenter is notified of new data (via the event bus), he reloads the view
I am thinking of two approaches to unit testing in this situation (let it be assumed that the async task is executed sequentially in one test thread):
It makes no sense to test each class in separation, because methods usually do not have logic, but only delegation. We can define a “block” at the level of the leader and his dependencies, down to the level of service (therefore, we should ridicule only the service). The result returned from the service must ultimately be delivered to the host, so we can test the full path.
The implementation of the event bus used depends on the Android (Green Robot) runtime, so for its use in the test we will create a smart fake, which is rather complicated. Thus, it would be better if the unit test ridiculed the event bus as an “external” dependency. Therefore, for our use case, we must separately test the leading path → the event bus and the event bus → presenter.
Which approach is better for my scenario?
The first one looks more intuitive: tests check to see if the user action leads to the correct view change. If we could execute the action synchronously, the manager, the asynchronous task and the event bus would be unnecessary - they are just templates that are not related to business logic. Am I missing something I would regret?
source share