Alovak thoughts |
Ruby/Rails developer Agile/TDD/BDD evangelist co-founder of Belorussian Agile and Rails communities |
My friend creates a large number of automation tests for service several teams work on. Recently we discussed different aspects of cucumber feature scenarios such as coupling and decoupling, conditional steps, etc.
The main question he wanted to clarify was how to handle horizontal integration tests when some steps in the middle are different? We reviewed different approaches for such cases.
As a developer I know if my tests become complex it’s an indicator that I do something wrong. What measures can I take?
The obvious solution is to refactor tests; wrap complex code blocks into fine named methods. A better solution is to simplify/refactor your code. The best solution is to simplify/refactor business logic.
In order to change business logic I need to communicate with Product owner (PO) and discuss with him problems I faced and to figure out what are the other possible ways to achieve the same business value.
Let’s back to my friend. Often the aim of automation testing is just to ensure that application works. What happens when an automation test became complex? I guess that the best solution taken in most cases is test refactoring. But instead of that you can reassess of the problem and think about real reasons of this complexity. Then you can discuss the ways how to simplify the application with developers and PO .