Cleaner context mocks (testing infrastructure for modules)

[adizere]

Summary

This issue is for discussing the problem of making mock context more modular & composable.

Problem

Currently, each ICS has its own context mock, designed specifically for unit testing the dispatch and handlers of that ICS. For instance, unit tests in ICS3 employ a MockConnectionContext comprising both a chain context and a client context.

https://github.com/informalsystems/ibc-rs/blob/2438ede7acac0c9481bebd77a13ca284d8b134c5/modules/src/ics03_connection/context_mock.rs#L15-L20

Similarly to MockConnectionContext, the mock context for ICS 26 also comprises a client context:

https://github.com/informalsystems/ibc-rs/blob/53d21475b14968c1e529e13da29deada5d84175c/modules/src/ics26_routing/context_mock.rs#L23-L26

The problem is as follows: neither of the client context members of MockConnectionContext and MockICS26Context is a reference, hence the test vectors for ICS26 will involve essentially two copies of a client context (one copy in the MockConnectionContext and another copy in MockICS26Context ). In other words, the problem is that the mock contexts structures are not composable, and hence involve a lot of clone operations leading to redundancy at the level of these structures. The straightforward solution to this is to make the client context members references, which would involve introducing lifetimes.

It's not clear if lifetimes are desirable or if they are the best solution.

Later Edit: @brapse proposed a solution that eliminates altogether dependencies across contexts. PRO: flat dependency space, no need for lifetimes or excessive clone(); CON: duplicate code.

LE2: @ancazamfir proposed a solution to have a single data structure that implements all the handler's reader & keeper traits. We can use this data structure to test any IBC handler.

Solution

We'll introduce a global mock context, which will serve in unit testing all and every IBC module. Towards making PRs smaller and more manageable, we break this work down by ICS:

• Cleaner context mocks for ICS2 informalsystems/hermes#296 introduce cleaner mock context for ICS2
• Cleaner context mocks for ICS3 informalsystems/hermes#295 introduce cleaner mock context for ICS3
• Cleaner context mocks for ICS18 and ICS26 informalsystems/hermes#297 cleanup ICS18 and ICS26 following the global mock context

Futher issues

• ICS02 should include tests for dispatch. More generally: align testing across the handlers of ICS02 and ICS03 (and others); tentative strategy: test process as well as keep separately, then test dispatch by comparing its output to the ones of process and keep (deferred here from Follow-up on message processor (handler) implementations #115). This was fixed in Cleaner context mocks for ICS2 informalsystems/hermes#296

Smaller aesthetic issues that should also be fixed with this work:

• Most MockXContext structures (for example MockConnectionContext) can be renamed to MockICSXContext (e.g., for connections we'd have MockICS3Context) not applicable, since all mock context were reunited in a single global structure MockContext
• Consider renaming context traits (ConnectionReader, ClientKeeeper) to also refer to explicit ICS rather than objects, so for instance ConnectionReader would be renamed to ICS3Reader not an obvious improvement, deferred to later..
• Move ChainReader and ChainKeeper and MockChainContext into ICS24 (host requirements). these traits/context were deleted
• Consider renaming ChainReader to ICS24Reader (same for keeper and context) these traits were deleted

The dependencies among contexts is as follows:

1. ICS18 context represents the dependencies of the relayer towards a chain
2. ICS24 context represents the dependencies of all ICS modules (in general, the sdk?) towards a chain
3. ICS26 context represents the dependencies of the routing module towards a chain
4. ICS2 and 3 (and 4) contexts are deps. of the client/connection/channel modules towards a chain

So we can refactor the contexts to follow this hierarchy: ICS18 -> ICS24 -> ICS26 -> ICS4, 3, 2

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned