Adding a unit test framework to scaffolded applications

[PaddyMc]

Description

To improve the code quality and allow a deeper understanding of what happening under the hood of cosmos-sdk powered applications, we could add a unit test framework to the starport scaffolding

Implementation Details

We should follow best practices when defining unit test frameworks, this usually means table-driven testing and using test suites.

A sample test suite for the keeper package could look like:

The keeper test suite will contain a context and other structures needed to run the keeper correctly

// Keeper test suit enables the keeper package to be tested
type KeeperTestSuite struct {
	suite.Suite

	ctx         sdk.Context
	keeper      Keeper
	queryClient types.QueryClient
	msgServer   types.MsgServer
}

The suite will be initialized by calling the SetupSuite() function which could look as follows: NOTE: we could initialise simapp here if we need some of the default keepers

// SetupTest creates a test suite to test the identifier
func (suite *KeeperTestSuite) SetupTest() {
	keyIdentifier := sdk.NewKVStoreKey(types.StoreKey)
	memKeyIdentifier := sdk.NewKVStoreKey(types.MemStoreKey)

	db := dbm.NewMemDB()
	ms := store.NewCommitMultiStore(db)
	ms.MountStoreWithDB(keyIdentifier, sdk.StoreTypeIAVL, db)
	ms.MountStoreWithDB(memKeyIdentifier, sdk.StoreTypeIAVL, db)
	_ = ms.LoadLatestVersion()

	ctx := sdk.NewContext(ms, tmproto.Header{ChainID: "foochainid"}, true, nil)

	interfaceRegistry := ct.NewInterfaceRegistry()
	marshaler := codec.NewProtoCodec(interfaceRegistry)

	k := NewKeeper(
		marshaler,
		keyIdentifier,
		memKeyIdentifier,
	)

	queryHelper := baseapp.NewQueryServerTestHelper(ctx, interfaceRegistry)
	types.RegisterQueryServer(queryHelper, k)
	queryClient := types.NewQueryClient(queryHelper)

	msgServer := NewMsgServerImpl(*k) <== this doesn't really work atm, sorry for adding it here

	suite.ctx, suite.keeper, suite.queryClient, suite.msgServer = ctx, *k, queryClient, msgServer
}

Finally to run the full test suite we would call the RunKeeperTestSuite functions which would look as follows:

func TestKeeperTestSuite(t *testing.T) {
	suite.Run(t, new(KeeperTestSuite))
}

Then adding tests to the keeper package would look as follows

func (suite *KeeperTestSuite) TestGenericKeeperSetAndGet() {
	testCases := []struct {
		msg        string
		identifier types.DidDocument
		expPass    bool
	}{
		{
			"data stored successfully",
			types.DidDocument{
				"context",
				"did:cash:1111",
				nil,
				nil,
			},
			true,
		},
	}
	for _, tc := range testCases {
		suite.keeper.Set(suite.ctx,
			[]byte(tc.identifier.Id),
			[]byte{0x01},
			tc.identifier,
			suite.keeper.MarshalIdentifier,
		)
		suite.keeper.Set(suite.ctx,
			[]byte(tc.identifier.Id+"1"),
			[]byte{0x01},
			tc.identifier,
			suite.keeper.MarshalIdentifier,
		)
		suite.Run(fmt.Sprintf("Case %s", tc.msg), func() {
			if tc.expPass {
				_, found := suite.keeper.Get(
					suite.ctx,
					[]byte(tc.identifier.Id),
					[]byte{0x01},
					suite.keeper.UnmarshalIdentifier,
				)
				suite.Require().True(found)

				allEntities := suite.keeper.GetAll(
					suite.ctx,
					[]byte{0x01},
					suite.keeper.UnmarshalIdentifier,
				)
				suite.Require().Equal(2, len(allEntities))
			} else {
				// TODO write failure cases
				suite.Require().False(tc.expPass)
			}
		})
	}
}

😄

[lumtis]

I really like the idea to follow strict rules for the tests to ensure developer follow best practices 👍

msgServer := NewMsgServerImpl(*k) <== this doesn't really work atm, sorry for adding it here

This is actually something important I think to implement before this feature. This is actually convenient to test handlers.
Until then, when I implemented tests for Cosmos SDK application I always "simulated" sending a message to the high-level handler and this is no more a good practice.
Create an issue for this: #717

[dshulyak]

Parts:

• unit tests for non-indexed type feat: basic unit tests for non-indexed type #1089
• unit tests for indexed type feat(templates): unit tests for indexed type #1105
• unit tests for ibc packet

@lubtd @ilgooz @fadeev please let me know what else I should include here besides things mentioned above

[fadeev]

@PaddyMc as the author of the issue (mad props btw!), can you comment on whether there is anything else you as a chain developer expect to see in the scaffold in terms of tests. For convenience, I've scaffolded a chain and ran starport type post title body. (this should include changes from 1105 and 1089)

https://github.com/fadeev/testchain/

[PaddyMc]

Not from my side! Great work @dshulyak

[dshulyak]

I will create another issue for IBC. It should be based on testing framework developed in https://github.com/cosmos/ibc-go/ , which simplifies testing code a lot.