LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

chore: enhance codebase clarity through systematic terminology corrections (#24976)

Browse Source
This commit is contained in:
bigbear 2025-07-24 17:53:54 +03:00 committed by GitHub
parent 161236e53d
commit 39bec15523
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
client/input/input_test.go
View File

@ -43,7 +43,7 @@ func TestReadLineFromBuf(t *testing.T) {
require.ErrorIs(t, err, io.EOF)
})
t.Run("it returns the error if it's not EOF regardles if it read something or not", func(t *testing.T) {
t.Run("it returns the error if it's not EOF regardless if it read something or not", func(t *testing.T) {
expectedErr := errors.New("oh no")
fr.fnc = func(p []byte) (int, error) {
return copy(p, []byte("hello")), expectedErr

4
docs/docs/build/building-modules/16-testing.md vendored
View File

@ -7,7 +7,7 @@ sidebar_position: 1
The Cosmos SDK contains different types of [tests](https://martinfowler.com/articles/practical-test-pyramid.html).
These tests have different goals and are used at different stages of the development cycle.
We advice, as a general rule, to use tests at all stages of the development cycle.
It is adviced, as a chain developer, to test your application and modules in a similar way than the SDK.
It is advised, as a chain developer, to test your application and modules in a similar way than the SDK.
The rationale behind testing can be found in [ADR-59](https://docs.cosmos.network/main/build/architecture/adr-059-test-scopes).
@ -59,7 +59,7 @@ In the SDK, we locate our integration tests under [`/tests/integrations`](https:
The goal of these integration tests is to test how a component interacts with other dependencies. Compared to unit tests, integration tests do not mock dependencies. Instead, they use the direct dependencies of the component. This differs as well from end-to-end tests, which test the component with a full application.
Integration tests interact with the tested module via the defined `Msg` and `Query` services. The result of the test can be verified by checking the state of the application, by checking the emitted events or the response. It is adviced to combine two of these methods to verify the result of the test.
Integration tests interact with the tested module via the defined `Msg` and `Query` services. The result of the test can be verified by checking the state of the application, by checking the emitted events or the response. It is advised to combine two of these methods to verify the result of the test.
The SDK provides small helpers for quickly setting up an integration tests. These helpers can be found at <https://github.com/cosmos/cosmos-sdk/blob/main/testutil/integration>.

2
store/pruning/manager.go
View File

@ -46,7 +46,7 @@ func (e *NegativeHeightsError) Error() string {
var pruneSnapshotHeightsKey = []byte("s/prunesnapshotheights")
// NewManager returns a new Manager with the given db and logger.
// The retuned manager uses a pruning strategy of "nothing" which
// The returned manager uses a pruning strategy of "nothing" which
// keeps all heights. Users of the Manager may change the strategy
// by calling SetOptions.
func NewManager(db dbm.DB, logger log.Logger) *Manager {

2
types/module/module.go
View File

@ -643,7 +643,7 @@ type MigrationHandler func(sdk.Context) error
type VersionMap map[string]uint64
// RunMigrations performs in-place store migrations for all modules. This
// function MUST be called insde an x/upgrade UpgradeHandler.
// function MUST be called inside an x/upgrade UpgradeHandler.
//
// Recall that in an upgrade handler, the `fromVM` VersionMap is retrieved from
// x/upgrade's store, and the function needs to return the target VersionMap