Writing tests that suck less!

Writing unit tests is easy, since testing functions is trivial. But the more high-level our tests become, the more they have to deal with the state and side-effects of our application. It becomes harder and harder to write proper tests. And worst of all: they are harder and harder to understand and to maintain, greatly diminishing the value of those tests as a documentation of your software.

On the other hand Acceptance Tests can be seen as the most important tests of our systems. They should be easy to read and to reason about. These tests have to clearly communicate the intent of the code under test.

In this talk I want to show how you can use simple strategies to tranform your acceptance tests to something, that clearly separate why is something tested, what is tested and how it is tested. These tests will be easy to grasp and to reason about, providing great value as an executable documentation of your systems.