Testing Methods in production code

[oxnr]

Finding 012 - Testing Methods in production code

ID	012
Finding	Testing Methods in production code
Severity	0 - Informational
Description	There are testing methods in production code, these testing methods also affect performance because a mutex lock is dependent on a component only used in testing.
Recommendation	Move the methods in a testing package, methods in testing packages can be accessed within testing context.
Code References	rollkit/block/manager.go Line 208 in eccdd0f func (m *Manager) SetDALC(dalc *da.DAClient) { rollkit/block/manager.go Line 213 in eccdd0f func (m *Manager) SetLastState(state types.State) { rollkit/block/manager.go Line 220 in eccdd0f func (m *Manager) GetStoreHeight() uint64 { rollkit/block/manager.go Line 225 in eccdd0f func (m *Manager) GetBlockInCh() chan NewBlockEvent { rollkit/block/manager.go Line 230 in eccdd0f func (m *Manager) IsBlockHashSeen(blockHash string) bool { rollkit/block/manager.go Line 235 in eccdd0f func (m *Manager) IsDAIncluded(hash types.Hash) bool { rollkit/block/block_cache.go Line 13 in eccdd0f daIncluded map[string]bool

[MSevey]

Test methods can only be accessed within the same package.

golang/go#31135

I believe the advice around defining exports in a test package only really applies to Functions which can live outside a package where an interface or struct is defined.

This methods, are working on unexported fields so they required being defined in the block manager package.

The only way to move them out of production code, would be to move the functionality entirely to mocks within the node package.

[MSevey]

The alternative would be to define an interface that can then be accessed within the tests. However the interface itself would still be defined within the production code.

Due to the minimal scope of this code, I recommend just closing this issue.

cc @Manav-Aggarwal