162 Chapter 11 Automate Literally Around 2010 I heard the term domain-specific test language for the first time. My first reaction was that there shouldn't be a discrepancy between the domain language that is used in your code and the one used in your tests at all. Sometimes--- for example, in a legacy code system---you have no other choice but to keep the two separated when you begin your ATDD journey. Over time, though, you should unify the two into a single ubiquitous language used in your project. If you keep the two separated, you are growing and fostering miscommunication with your project stakeholders. One way to achieve this is to drive the domain code directly from your examples. Let's take a closer look on these three aspects: Agile- and ATDD-friendly test automation, collaboration between programmers and testers, and finally how to discover the domain and a sufficient and appropriate domain model from your examples. Use Friendly Automation I heard the term ATDD-friendly test automation for the first time when I attended a tutorial on ATDD held by Elisabeth Hendrickson in 2009. It indicates that there