Testing stage 2018

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.

Test automation - the supporting architecture

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.

Why is good design important for test automation?

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.

Acknowledgements

I would like to thank Malin Ekholm for reading and finding typos.

Resources



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
DevOps
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Javascript
Kubernetes
Linux
Load testing
Maven
Mockito
New developers
Pair programming
PicoContainer
Presentation
Programming
Public speaking
Quality
React
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS