How to Structure a Scalable And Maintainable Acceptance Test Suite

How
to Structure a Scalable And Maintainable Acceptance Test Suite

07/20/10 by Andreas
Ebbert-Karroum

5
Comments

Robot Framework Tutorial

Part I: Robot Framework Tutorial – Overview

Part II: Robot Framework – A complete example

Part III: Robot Framework IDE

Part IV: How to Structure a Scalable And Maintainable Acceptance Test Suite

Part V: Robot Framework Tutorial – Writing Keyword Libraries in Java

Part VI: Robot Framework Tutorial – Loops, Conditional Execution and more

Part VII: Robot Framework – Testing Windows Applications

Appendix A: Robot Framework – Compact Sheet

The new Robot Framework Tutorial 2016 series

You started to write automated acceptance tests, so that you don’t need to retest all the results from earlier sprints at the end of every sprint. Greate, we too. After a while of successful test automation, tests start to look like a big ball of mud instead
of a cleanly designed test suite. Darn, same for us. Where did we go wrong? Over time, we established a few patterns and best practices, that lead to a scalable and maintainable test infrastructure, which I would like to present in this post.

I will only consider the structure of the tests itself, neglecting all considerations regarding the execution (logging, paralellisation) or test hardware. It was mentioned a couple of times already: we’re using the robot framework for automating our acceptance
tests, thats why some of the presented solution will be specific to the robot framework. But most will be applicable to other test frameworks: users of FitNesse, Cucumber, Concordion, etc., don’t stop reading here