From 39bec1552306e47073bc9203ce55f36489a4b9d8 Mon Sep 17 00:00:00 2001 From: bigbear <155267841+aso20455@users.noreply.github.com> Date: Thu, 24 Jul 2025 17:53:54 +0300 Subject: [PATCH] chore: enhance codebase clarity through systematic terminology corrections (#24976) --- client/input/input_test.go | 2 +- docs/docs/build/building-modules/16-testing.md | 4 ++-- store/pruning/manager.go | 2 +- types/module/module.go | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/client/input/input_test.go b/client/input/input_test.go index 3132afcdfa..f28a9c3905 100644 --- a/client/input/input_test.go +++ b/client/input/input_test.go @@ -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 diff --git a/docs/docs/build/building-modules/16-testing.md b/docs/docs/build/building-modules/16-testing.md index 3dc4c3419e..c899aa8fae 100644 --- a/docs/docs/build/building-modules/16-testing.md +++ b/docs/docs/build/building-modules/16-testing.md @@ -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 . diff --git a/store/pruning/manager.go b/store/pruning/manager.go index 7c95bc6694..d4138a0218 100644 --- a/store/pruning/manager.go +++ b/store/pruning/manager.go @@ -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 { diff --git a/types/module/module.go b/types/module/module.go index 13e26a8387..a48c5ab4d8 100644 --- a/types/module/module.go +++ b/types/module/module.go @@ -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