Write ADR for IBC testing package++

[colin-axner]

Summary

The testing package is heavily used by our code base as well as by external IBC applications. It has undergone significant refactors thanks to external feedback along with our own usage. Updating to ABCI++ will require another refactor due to the current block execution structure being incompatible.

The testing package is simultaneously robust and fragile. Many design decisions have been made due to subtle understandings of tendermint and the SDK. These design choices should be documented so we can easier reason about potential changes in the future. Discussion on this ADR will also give us space as a community to discuss the potential improvments/requirements.

Problem Definition

The testing package has accrued a long history and will break with ABCI++. The current and future design decisions should be clearly documented.

This problem needs to be addressed

Proposal

Write an ADR outlining the context of the testing package, its history, and the future changes required for it to align with ABCI++

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[colin-axner]

There are now a serious of proposed changes in the Testing package improvements milestone. Maybe we could at least add an ADR documenting all the changes made

The abci++ changes initially are less substantial than I anticipated and has mostly lead to clean up in the testing pkg

[DimitrisJim]

+1 for ADR.

Since testing is a package other people use, it might be sensible to loop them in here. One way this is done is via RFCs whereby interested parties can contribute to the discussion. RFC fleshes out the initial details and creates consensus around some specific architectural decision while the ADR will document that final decision.

I am unsure if it is entirely warranted, it might be overkill and not something the team wishes to go through. In general I'd find it beneficial to introduce this separation as I do think having a process that would likely make other voices heard could be beneficial.

[colin-axner]

Gonna close this issue, as I don't think it makes much sense to dedicate effort to it. Would be nice, but the testing package isn't so complicated