[Feature]: module level testing

[tac0turtle]

Summary

Currently modules rely on consensus level steps (finalizeblock) to begin a new block in testing. This is a legacy design as a module should only worry about the steps of a state machine and how they are called when a consensus engine would give the application a block to execute.

Currently the sdk has a begin, end block and execute txs. This issue proposes we make finalize block and the steps of consensus private to baseapp and only expose logic that is needed for a module to execute (i.e. beginblock, devliertx and endblock). this would be a partial revert of the migration to finalize block that was done as part of 0.50.

Problem Definition

Modules deal with consensus level steps that group application steps together, which could make testing and debugging harder.

Proposed Feature

Explore exposing begin and endblock to modules for testing while making the steps of abci private to baseapp.

ref #17425

[facundomedica]

I've explored exposing begin and endblock to modules but at the moment there's some setup for the state and context happening in FinalizeBlock that is required. Also, all of these functions are currently using app.finalizeBlockState.ctx regardless of the context passed

[robert-zaremba]

Is this blocking v0.50 release?

[Olshansk]

@tac0turtle Is there a recommended way to testing business logic in EndBlock / BeginBlock handlers? Not looking for an explanation but just a link/pointer (if one exists) that you'd point to as a good reference to follow or learn from.

[tac0turtle]

this is more or less completed now. We have moved away from calling begin endblock from comet as it is no longer a comet level design. Since this is the case we can close this as all the types for begin/endblock have been moved to cosmossdk.io/core

[Olshansk]

Noted @tac0turtle. Posting here for posterity and as a reference to others.

I actually ended up doing a workshop at Modular Summit about our local development environment: https://www.youtube.com/watch?v=mDldfwaGtOI&t=1609s.

With respect to integration testing specifically. A search for NewCompleteIntegrationApp links to what our approach ended up being (see screenshot below).

The way we define (since it's nuanced and opinionated on a per-team per-project basis) Integration Testing is:

1. No Mocks (easier to maintain and real)
2. Not a simulation
3. Not true E2E (doesn't require infrastructure or service management)
4. Tests more than just unit tests
5. Validates lifecycle-based logic (e.g. across blocks)