172 Chapter 12 Test Cleanly You can also add large behavior flows like adding an account with an address in your class directly. This approach is as bad as putting all the business logic in the GUI classes of your application. First of all, you create a code base that is hard to test automatically through unit tests on its own. The object model of your test code lacks the existence of commonly used domain objects like money and an AccountCreator. Eventually, your team members will lack an understanding of how to deal with the code that you created and keep reinventing the wheel. In the worst case, you end up with a large test support code base that is copied and pasted together. At this point you already have shot yourself in the foot with your test automation efforts as new features become harder and harder to automate based on that. If you build your support code in components, you create independent helpers that you can include or extend in the future. In the traffic lights example we extracted the concept of a CrossingController as a component. Although we actually put it in our domain model in the end, the crossing controller is an example of such an independent component. As we saw later, there is another advantage to building small components for your test automation support code. Independent components are easier to unit test in themselves. Since test automation is software development, you should consider unit testing more complex flows through the support code on its own. As I mentioned in Chapter 9, I once heard from a team where test-driving the test automation code led to a major increase (10--15%) in test coverage in the whole system. If you find yourself adding one if or switch statement after another, consider refactoring your code to a more object-oriented structure such as a strategy pattern [GHJV94] or an independent component. Listen to the Tests Unit tests can teach you a lot about the design of your classes [FP09]. If the unit tests are awkward to write---and read for that matter---they may give you hints to a missing concept in your design. From my experience, this does not only hold for unit tests, but also for acceptance tests. If you need a lot of support code---especially complicated with many nested if s---this implies a missing concept either in your application or in your support code. If you have built your acceptance criteria on business examples, it's most likely that your application is missing a domain concept. We saw an example of this with the traffic lights example. There we took the tests and the support code to motivate the domain concepts in the code. This is one way to listen to your tests and drive your implementation from these.