Design unit test cases

I need a set of unit tests for a class Account that implements deposit, withdraw, and transfer with overdraft rules. Use a lightweight test style and cover normal, boundary and error cases: deposit positive, deposit zero, withdraw within balance, withdraw to zero, withdraw exceeding balance throws, transfer between two accounts updates both balances atomically or rolls back. Include exact assertions and which mocks (if any) are necessary.

Before I run these tests on CI, make the cases easy to evaluate: surface the five critical assertions up front (balance after ops, exception on overdraw, atomicity of transfer, no silent negative balances, event emission), make the expected preconditions explicit, and flag which tests are flaky or slow and why (timing, randomness, external services).

A transfer unit test fails intermittently on CI with one account showing stale balance while local runs are fine. I already checked locks and run with single thread locally. I need to tell the team what I did, who owns the account code, what I fear (race condition or shared global state in tests), and ask: what is the most likely diagnosis and the quickest reliable next step to stabilize CI while we debug further?

Across projects we keep writing unit tests that hit a real database or external service, making CI slow and flaky. This costs developer time and obscures real failures. Which habit should I change to reduce this waste: propose a testing pyramid change, a fast in-memory or mocked layer pattern, and one mandatory rule for new tests to keep CI fast and reliable.