BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Programming Foundations for Test Automation

Programming Foundations for Test Automation

Proper programming foundations can improve your test automation, making it easier to maintain testing code, and reduce stress. A foundation of the theory and basic principles of coding and programming can help to bring test automation to the next level. Object-oriented programming principles can help to overcome code smells.

Christian Baumann spoke about test automation at Agile Testing Days 2022.

Baumann mentioned that a lot of testers are "thrown" into test automation without a profound background in programming, or without having received any proper training. These people have some idea of what tool to use and managed to create some automated tests with it. At a certain point, they suspect that something is not quite right with their automation, Baumann said. The code feels messy, maintaining it costs a lot of time, and it’s very frustrating.

It would be great if everybody doing test automation would get a proper foundation in terms of the theory and basic principles of coding and programming, Baumann stated. This in order to also produce high quality automation code.

Baumann gave an example of how to use object-oriented programming principles in our test automation:

We can use the object mother pattern which uses the object-oriented principle of "abstraction". This means, it hides internal implementation details, and reveals only methods that are necessary to use it. How test objects are created in detail, how they are deleted from the database, how they are modified during a test - all of that is not necessary for the user to know; all that the user needs to know is that these methods exist and can be called.

Using object-oriented programming principles can also help to overcome code smells, as Baumann explained:

Eliminating code smells means, to change the code, without changing the code’s behaviour, which basically is the definition of refactoring; and for refactoring, we need unit tests as a safety net, so we know that with our changes we did not break anything and the code is still working as intended.

Baumann suggested that test automation code should be valued and treated as the production code of the applications we are building, to prevent running into similar problems.

InfoQ interviewed Christian Baumann about programming foundations for test automation.

InfoQ: What benefit can object-oriented programming principles bring?

Christian Baumann: Applying object-oriented programming principles in test automation code is of great help, by making the code less prone to errors, and also making it easier to read, understand and maintain.

InfoQ: What can be done to take good care of our test data?

Baumann: In the context of test automation, I believe the best approach to deal with test data is that each test is responsible for its very own data. This means that each test creates the test data it needs as part of its test setup. At termination of the test, the data is being deleted again from the system, leaving the test environment in a clean state.

The object mother pattern can be of great help in doing so. It starts with the factory pattern and provides prefabricated objects that are ready to be used in tests via a simple method call. But it goes far beyond the factory pattern, because the created objects can be customised; also test objects can be updated during the test, and furthermore -if necessary- at the end of the test, the object is being removed again from the database.

InfoQ: How can we recognize and eliminate code smells?

Baumann: In order to recognize code smells, one needs to know them. Therefore, as a programmer (what we are if we write test automation code), we need to learn and study them.

For certain code smells, certain "recipes" can be used to eliminate them; for example, applying the OOP principle "polymorphism" helps to eliminate the "switch statement" code smell as well as the "too many arguments" smell.

About the Author

Rate this Article

Adoption
Style

BT