The automated tests that we write contain many languages. The programming language, of course, but also the language of the frameworks we use, and the domain language.

For example, in web tests, we use terms like "TextArea" and "Div". While these are the test mechanics, they do not convey the meaning of the test. When we use terms from the domain language, like "attendee" and "registration", we understand them better and can modify them without errors. The problem is we end up using both languages, sometimes more, in the same tests.

The mash-up of languages creates Frankenstein's tests. This is bad. The tests are not readable, open to interpretation, and are hard to understand and maintain. We need to find the original purpose of the test behind the tools' language. In the age of test code generation, the problem gets worse.
There are many good practices about refactoring code, modularizing it, using known patterns. This talk is not about them. It is about using the right language in the tests, and hiding the languages of the tools we use.

I'll show the impact of using different combinations of domain and low-level languages, in both API and web tests, and what are the costs involved on keeping the tests in franken-mode. I'll discuss how to improve on the situation, and what traps to avoid, in order to minimize that work in the first place.
The monster is coming. We need to be on the lookout and fix the problem.

Takeaways:

1. We write tests using common frameworks, sometimes generate them completely. We mix & match low-level and domain languages, and our tests end up looking like Frankenstein’s monster.
2. The language mix causes readability and maintainability issues. They impact the cost and risk of understanding, debugging and modifying the tests.
3. With proper names, abstraction principles and code organization methods, we can lower the maintenance pain.