## Description This PR introduces the `cmdtest` package, offering a lightweight wrapper around cobra commands to simplify testing CLI utilities. I backfilled tests for the `version` command, which was an example of a very simple test setup; and for the `export` command, which was more involved due to the server and client context requirements. I did notice that there are some existing tests for some utilities, but the `cmdtest` package follows a simple pattern that has been easy to use successfully in [the relayer](https://github.com/cosmos/relayer/blob/main/internal/relayertest/system.go) and in other projects outside the Cosmos ecosystem. While filling in these tests, I started removing uses of `cmd.Print`, as that is the root cause of issues like #8498, #7964, #15167, and possibly others. Internal to cobra, the print family of methods write to `cmd.OutOrStderr()` -- meaning that if the authors call `cmd.SetOutput()` before executing the command, the output will be written to stdout as expected; otherwise it will go to stderr. I don't understand why that would be the default behavior, but it is probably too late to change from cobra's side. Instead of `cmd.Print`, we prefer to `fmt.Fprint(cmd.OutOrStdout())` or `fmt.Fprint(cmd.ErrOrStderr())` as appropriate, giving an unambiguous destination for output. And the new tests collect those outputs in plain `bytes.Buffer` values so that we can assert their content appropriately. In the longer term, I would like to deprecate and eventually remove the `testutil` package's `ApplyMockIO` method and its `BufferWriter` and `BufferReader` types, as they are unnecessary indirection when a simpler solution exists. But that can wait until `cmdtest` has propagated through the codebase more. --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] ~~provided a link to the relevant issue or specification~~ - [x] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed all author checklist items have been addressed - [ ] confirmed that this PR does not change production code |
||
|---|---|---|
| .. | ||
| api | ||
| cmd | ||
| config | ||
| grpc | ||
| log | ||
| mock | ||
| types | ||
| cmt_cmds.go | ||
| constructors_test.go | ||
| doc.go | ||
| export_test.go | ||
| export.go | ||
| pruning_test.go | ||
| pruning.go | ||
| README.md | ||
| rollback.go | ||
| start.go | ||
| swagger.go | ||
| util_test.go | ||
| util.go | ||
Server
The server package is responsible for providing the mechanisms necessary to
start an ABCI Tendermint application and provides the CLI framework (based on cobra)
necessary to fully bootstrap an application. The package exposes two core functions: StartCmd
and ExportCmd which creates commands to start the application and export state respectively.
Preliminary
The root command of an application typically is constructed with:
- command to start an application binary
- three meta commands:
query,tx, and a few auxiliary commands such asgenesis. utilities.
It is vital that the root command of an application uses PersistentPreRun() cobra command
property for executing the command, so all child commands have access to the server and client contexts.
These contexts are set as their default values initially and maybe modified,
scoped to the command, in their respective PersistentPreRun() functions. Note that
the client.Context is typically pre-populated with "default" values that may be
useful for all commands to inherit and override if necessary.
Example:
var (
initClientCtx = client.Context{...}
rootCmd = &cobra.Command{
Use: "simd",
Short: "simulation app",
PersistentPreRunE: func(cmd *cobra.Command, _ []string) error {
if err := client.SetCmdClientContextHandler(initClientCtx, cmd); err != nil {
return err
}
return server.InterceptConfigsPreRunHandler(cmd)
},
}
// add root sub-commands ...
)
The SetCmdClientContextHandler call reads persistent flags via ReadPersistentCommandFlags
which creates a client.Context and sets that on the root command's Context.
The InterceptConfigsPreRunHandler call creates a viper literal, default server.Context,
and a logger and sets that on the root command's Context. The server.Context
will be modified and saved to disk via the internal interceptConfigs call, which
either reads or creates a Tendermint configuration based on the home path provided.
In addition, interceptConfigs also reads and loads the application configuration,
app.toml, and binds that to the server.Context viper literal. This is vital
so the application can get access to not only the CLI flags, but also to the
application configuration values provided by this file.
StartCmd
The StartCmd accepts an AppCreator function which returns an Application.
The AppCreator is responsible for constructing the application based on the
options provided to it via AppOptions. The AppOptions interface type defines
a single method, Get() interface{}, and is implemented as a viper
literal that exists in the server.Context. All the possible options an application
may use and provide to the construction process are defined by the StartCmd
and by the application's config file, app.toml.
The application can either be started in-process or as an external process. The former creates a Tendermint service and the latter creates a Tendermint Node.
Under the hood, StartCmd will call GetServerContextFromCmd, which provides
the command access to a server.Context. This context provides access to the
viper literal, the Tendermint config and logger. This allows flags to be bound
the viper literal and passed to the application construction.
Example:
func newApp(logger log.Logger, db dbm.DB, traceStore io.Writer, appOpts server.AppOptions) server.Application {
var cache sdk.MultiStorePersistentCache
if cast.ToBool(appOpts.Get(server.FlagInterBlockCache)) {
cache = store.NewCommitKVStoreCacheManager()
}
pruningOpts, err := server.GetPruningOptionsFromFlags(appOpts)
if err != nil {
panic(err)
}
return simapp.NewSimApp(
logger, db, traceStore, true,
baseapp.SetPruning(pruningOpts),
baseapp.SetMinGasPrices(cast.ToString(appOpts.Get(server.FlagMinGasPrices))),
baseapp.SetHaltHeight(cast.ToUint64(appOpts.Get(server.FlagHaltHeight))),
baseapp.SetHaltTime(cast.ToUint64(appOpts.Get(server.FlagHaltTime))),
baseapp.SetInterBlockCache(cache),
baseapp.SetTrace(cast.ToBool(appOpts.Get(server.FlagTrace))),
)
}
Note, some of the options provided are exposed via CLI flags in the start command
and some are also allowed to be set in the application's app.toml. It is recommend
to use the cast package for type safety guarantees and due to the limitations of
CLI flag types.