If you’re a programmer, chances are you’ve heard about “Test-induced design damage”. This catchy phrase, coined by Ruby on Rails author David Heinemeier Hansson, implies that the dogmatic practice of Test-driven development can harm the structure of the software it’s meant to protect. Besides its sensationalism, that statement served to take a step back and reason about the practice of writing automated tests. What compromises do we make to gain the confidence of a well-covered code base? Do automated tests inhibit good design? In this session we’ll explore those questions by looking at how writing automated tests affects our design choices. We’ll look at approaches like BDD and Specification by Example and how they use tests as a way to lead the design to fit its purpose. We’ll also look at balancing unit tests with integration and end-to-end tests in order to decouple our tests from the internal structure of the system. All to achieve the honorable goal of writing tests with no harm done.