testing with mocked db or store / store functions

[jchappelow]

Presently a number of unit tests rely on a functional postgresql database. This OK for tests that mean to provide a quick test of well-integrated high level types (or are actually testing SQL functionality like the pg package or engine integration tests), but for packages like consensus engine, we need to find an approach that can satisfy the test without the actual DB.

approaches

• for dependencies that necessitate a SQL DB: (1) if there is a package like voting store or chain meta store that requires a DB instance in its function args, define overrides for these functions, (2) if there is a stateful type that requires a DB instance in its constructor or methods, mock the type to satisfy the interface
• As our stores need to become more stateful anyway for efficiency reasons, start moving toward types that can be mocked more easily as in (2) above.
• very hard, mock the sql DB/Tx interfaces. This is hard or even impractical since it tightly couples with consumer because the sql statement is a string that the mock would have to recognize. This is unlikely to be a good approach as a result. Only in some very narrow cases would this be good.

This is less important for the kinds of tests in node_live_test.go where we are actually trying to make a fast integration test within the go test framework. However, even in TestDualNodeMockNet it would be nice to have a way to test the combined node/p2p+CE functionality with two in-memory node instances that don't need postgres. For example, we have an in memory block store (node/store/memstore) but we do not have similar for the types that use postgres.