>>> from itertools import product
>>> twokids = product('B G'.split(), 'M Tu W Th Fr St Sn'.split(), repeat=2)
>>> boytues = [t for t in twokids if t[:2]==('B', 'Tu') or t[2:]==('B', 'Tu')]
>>> twoboys = [t for t in boytues if t[0] == t[2] == 'B']
>>> len(twoboys)
13
>>> len(boytues)
27
* The need to rapidly iterate and refine strategies is not supported by writing tests which can prematurely lock-down the logic. Likewise, freezing the business logic with tests can become an impediment to adapting to changing market conditions (some opportunities have a short life).
* Like chess and poker games, the opponents have a say in how the logic plays-out. You will not be able to create a mock-object that accurately simulates how the rest of the market will respond to your bids and offers.
* Trading can be viewed as a concurrency problem. A flood of messages (orders and cancels) from independent actors (your competitors) go into an exchange computer which matches orders and emits quotes -- this is a race condition by design. Behaviors of concurrent systems with race conditions are notoriously hard to test.
* The OP mentions an order simulator (fake orders used for testing) but should be aware that that system can introduce a new risk, that of failing to switch the inputs when going live with a strategy. I've seen this happen (fake orders in, live orders out, not good).
* For managing risks, there are reasonable alternatives to testing. For example, strategy monitoring can shut down a program with order streams that are too large, too frequent, or that accumulate large positions. These dynamic reasonable checks provide protection against irrational strategy logic. Dynamic monitoring of trading logs provide real-time logic validation (i.e. with the actual inputs received, did the strategy make correct decisions).
Many components of a trading system are unittestable, but the strategy engine (the business logic) is more amenable to other techniques.