testing reducers

What's the workflow for testing a module's public API? I want to test it during the module build. My wishlist includes:

• run a test or collection of tests in an isolated database environment - different test suites may have isolated environments
• custom database pre-population or starting state for a test
• retain database for failed test
• call into the reducer as if a client
• peek into the db as if on the server
• manage multiple identities so that we can test interactions between different identities interacting with the same db
• module test source lives in the module source tree
• not touch any production environments in any way

So for example, I may want to check that identity A can call a reducer to rename themselves, and that identity B gets notification of A's name change, and that B can not change the name of A. This would require a database with identity A and B pre-initialized and nothing else, and the post-test database state would reflect the updated name for A. I think this means the test would need to create a new DB instance, populate it, then acquire two independent clients for A and B, and potentially allow some state-inspection sql to be run as if inside the database, e.g. to verify the identity name table state.

I am trying to avoid testing the module by either going through random client ux clicking hell, or writing endless "fake" clients that run a particular test but aren't integrated into the build process, or being forced to make tables public to test them.

The issue names no files, tests, or entry points; start by reviewing the module build and existing reducer and client-testing interfaces. Done would require an integrated test workflow covering isolated databases, custom initial state, multiple identities, reducer calls, database inspection, failure retention, and protection from production environments.