One of the nice advantages of Test Driven Development is that it forces you to write modular code: it is not easy to test code that is not modular. Thus, either you give up on testing (an option which the author hopes you will never consider) or you decouple modules to easily test them. If you did not adopt this methodology from the beginning, remember that it is always possible to refactor the code to make it more modular and more testable. Thus, TDD and modular/decoupled design goes hand in hand and drives quality; well designed modular code is easier to test and well tested code has a known quality.
When evaluating whether to accept this programming methodology, you should also take into consideration that testing UI aspects is usually harder (as the examples in this chapter have shown). Thus, you should try to isolate the code that does not depend on a running Eclipse. Fortunately, in a DSL implementation this is easy.
Let us consider our quickfix provider we implemented...
