example repo, not the minimal counter module example, because the fuller module includes the testing surfaces needed for these examples.
Three testing levels
Keeper unit tests
Keeper unit tests verify keeper logic in isolation, without starting a full application. They construct a minimal in-memory context with a real KV store, initialize the keeper under test, and call its methods directly. No server, no network, no block processing. The counter module keeper tests live inx/counter/keeper/keeper_test.go. The test suite sets up a keeper with a live store and mock dependencies:
testutil.DefaultContextWithDB creates a real KV store backed by an in-memory database. moduletestutil.MakeTestEncodingConfig returns a codec configured for the test. The MockBankKeeper replaces the real bank keeper with a struct whose behavior can be controlled per test case:
msg_server_test.go uses the same suite to test the MsgServer layer, including event emission:
Integration tests
Integration tests verify behavior across the full application stack. They start a real in-memory network with one or more validators, wait for blocks to be produced, broadcast actual signed transactions via gRPC, and query the resulting state. These tests exercise the AnteHandler, message routing, block execution, and state commitment together. The counter module integration tests live intests/counter_test.go. The test suite uses testutil/network from the Cosmos SDK to spin up a full in-memory chain:
NewTestNetworkFixture (in tests/test_helpers.go) constructs the ExampleApp with dbm.NewMemDB() and returns a network.TestFixture that configures the in-memory validator. This lets the SDK’s network test helper start a real application with real consensus.
A test that exercises the full transaction path:
Simulation tests
Simulation tests are property-based tests. Instead of testing specific inputs, they generate large volumes of random operations and verify that the application’s invariants hold throughout. They catch bugs that deterministic test cases miss: unexpected ordering effects, state corruption under high load, and invariant violations that only appear after many sequential operations. The Cosmos SDK simulation framework drives this throughsimsx. The counter module defines a message factory that generates random MsgAddRequest messages:
sim_test.go wires everything together:
//go:build sims build tag means simulation tests are excluded from regular go test runs and only execute when explicitly requested with -tags sims. This keeps CI fast.
The simulation manager is initialized in app.go:
NewSimulationManagerFromAppModules collects simulation support from all modules that implement AppModuleSimulation. RegisterStoreDecoders registers human-readable decoders for each module’s store entries, used when the simulation framework logs state for debugging.
Test utilities
testutil
Thetestutil package provides helpers for constructing in-memory contexts for unit tests:
testutil.DefaultContextWithDBcreates a realsdk.Contextbacked by an in-memory KV store. Keeper unit tests use this to get a realistic execution context without starting a full node.moduletestutil.MakeTestEncodingConfigreturns a codec with standard interface registration, suitable for keeper tests.baseapp.NewQueryServerTestHelpercreates aQueryServiceTestHelperthat implements both the gRPC Server and ClientConn interfaces, allowing keeper tests to register query services and invoke them directly without a network connection.
testify suite
The SDK’s test files use thetestify/suite package. A suite.Suite groups test setup, teardown, and test methods into a single struct. SetupTest runs before each test method; SetupSuite runs once before all tests in the suite.
suite.Run discovers methods on the struct whose names start with Test and runs them as individual test cases. s.Require() returns assertion helpers that stop the test immediately on failure, while s.Assert() continues after a failure.
simsx and simd
simsx is the simulation execution framework. It provides:
SimMsgFactoryFn: a function type that implements theSimMsgFactoryXinterface for message factories. Each factory selects random accounts and parameters, constructs a message, and returns it for execution.ChainDataSource: provides access to random accounts, balances, and other chain data during message construction.SimulationReporter: allows a factory to signal that it should be skipped (for example, if no suitable account exists).simsx.Run: the top-level entry point that drives a full simulation run against the application.
simd is the reference simulation binary provided by the Cosmos SDK. It is a fully configured simapp (simapp) compiled as a standalone binary, used to run simulations against the SDK’s own module set without setting up a custom chain. For a custom chain like the example app, you use your own binary with the sims build tag. To learn how to run an example chain, visit the simd node tutorial.
To run simulations against the example app: