We are often faced with trying to test software that is closely coupled to some kind of framework. Examples include visual components (e.g. widgets, dialogs, etc.) and transactional component plug-ins. Testing these objects is hard because it can be expensive or impossible to construct all the objects that our system under test (SUT) needs to interact with. In other cases we have objects that are hard to test because they run asynchronously; examples include active objects (e.g. threads, processes, web servers, etc.) and user interfaces. Testing these objects is hard because the asynchronicity introduces uncertainty, interprocess coordination and the need for delays in tests. Faced with all these issues developers often just give up on testing this kind of code.