Filed under: Cucumber, Executable specification, Presentation, Selenium, — Tags: Behaviour-Driven Development, Gherkin, The four rules of simple design — Thomas Sundberg — 2018-03-26
In April I will be talking at Testing stage in Kiev, Ukraine
I have two sessions:
They are connected in the sense that they are both about how to implement the support code you need for your test automation initiative. As a developer, I know that how you implement code is really important. It is ultimately a matter of maintainability. And maintainability is probably the most important property a piece of code can have after being correct. Code that can't be maintained will create problems for you during the entire lifetime of your product.
It is all about the code you need behind the scenes when you use tools like Cucumber. It is really easy to be charmed by the simplicity in translating an executable example into code that actual does the execution. Unfortunately, it is easy to create steps that are complicated and hard to maintain.
Using the right architecture will allow you to test your application at different levels. It will allow you to test through the user interface as well as under the hood connected to the core of your application.
Both levels are important. Testing through the user interface allows you to be sure that the user will find an application that works. Testing at a deeper level allows for a faster and more thorough verification.
This is achieved by applying techniques software developers have been using for a long time. Push complexity into places where it is easier to handle using good abstractions.
The result will be a solution where we can concentrate on one thing at a time. Translation of concrete examples to code, driving the system under test, asserting properties important for the business. These are all examples of things that are important. They are also examples of things that I prefer to think of in isolation. My brain can only handle a few things at the same time. This is far as I understand true for most of us, we are able to keep 5 ± 2 in our head at the same time. Too many details confuse us. Complexity is about too many details at the same time.
I will show an example that supports verification at different levels. It will use the same steps, but the supporting code will drive the system under test in different ways.
Good design will make it easier to understand and use anything. This is true for most things in life, also for software. Placing the proper details in the proper place will make it easier to understand what a program does. This is especially true for test code. The test code is one important part of your production tools. If you don't understand what it does, how can you be sure it does the right thing?
I will start with a Selenium test suite that works, but is too hard to understand. I will, step by step, transform it into something that is easier to understand by applying the four rules of simple design. The end goal is something that is easier to understand and maintain.
The result will be published on Github where all small steps are committed so you should be able to follow the evolution and understand what happened at every stage.
I would like to thank Malin Ekholm for reading and finding typos.
RSS