The Robot Uprising - A Tale of Automated Testing

Ah testing, it’s one of those love/hate relationship type things. I see writing tests like brushing your teeth; it's just something you need to do because if you don’t, you’ll regret it in the long term when everything goes wrong and it’s going to cost you big time to fix! So, just like maintaining your dental hygiene can be a tedious task, so can test automation but alas, there are tools out there to make life a bit easier and choosing the right one can save you a lot of time, money and effort.

Now as you, my astute readers might know, there are many different types of testing. In fact, this website lists over 100 different types of testing! That’s a little too many for my liking, but hey it’ll hopefully keep us employed during the robot uprising, given that they'll need to be tested as well. Speaking of robots, this blog is primarily about the Robot Framework and how it has done wonders for at least one of those 100 types of testing - Acceptance Testing, and really what else is more important than your customer accepting your solution and handing over your hard-worked earnings.

Here comes the obligatory “what is the Robot Framework?” section. Well, the Robot Framework is used for acceptance test-driven development (ATDD). What that basically means is you have promised that your solution can do X, Y, and Z but you may or may not have developed the functionality. So, by using Robots keyword and data-driven test automation capability, your write test suites, and test cases that invoke REST APIs, run CLI commands over SSHclick things on a webpage and basically prove that your solution does what you promised it would do, so when you run the entire test suite and it comes out all green, you can comfortably look your customer in the eye and say "show me the money!".

Okay great, now that we know what the Robot Framework is, and why it’s useful, how do we use it? The best place to start is the quick start article, but we will cover the basic concepts here. So first thing’s first, we need to install it. Installing Robot is simple if you have python and pip installed. Simply run pip install robotframework. You will now be able to run robot --help and see all the wonderful different ways you can run your tests (see executing test cases for more information).

I find examples helpful when trying to get concepts across, so for the remainder of this blog, let’s pretend our company Asimov General Appliances is creating a REST API driven toaster. This toaster is very much like your printer, you load a loaf of bread in at the beginning of the week and you use an app on your smartphone to create toast on demand, heck let’s add Siri and scheduling integration as well. Now we as testers have been commissioned to write our automated tests using the Robot Framework to ensure this amazing new toaster does what the marketing and sales departments say it does and it will be up to the developers to implement it. Voila, you have acceptance test-driven development!

The bulk of the action happens within a test case, a test case can look a little like this:

*** Test Cases ***
Toaster can make toast    # Test case name, it represents a use case we are trying to prove works
    [Documentation]    Tests if toaster can make eatable toast, assumes fresh bread is in spooler
    Feed Bread In To Toaster # A keyword with no argument that does some action 
    Start Toasting
    Wait For Toast    30 # Another keyword this time with an argument, saying lets wait 30 seconds 
    Stop Toasting
    ${toast}=  Eject Toast    # A keyword that returns a value, that we can assert if it matches some criteria
    Should be toasted and eatable  ${toast} # A keyword doing some assertion with an argument, using the toast
variable we received from the previous keyword.

This is an example of a workflow-driven test, the workflow being a particular way your solution might be used which meets some acceptance criteria. You might be thinking this is some sort of witchcraft, to write such plain English and have some toast actually be made. So let me explain what is happening under the hood.

Ultimately the keywords are where the magic takes place. Keywords come from two places: Libraries or from the keywords we as testers write, also known as User Keywords. Library keywords are implemented in standard programming languages, typically Python. User keywords are just higher-level keywords that encapsulate one or more keywords. These are typically defined within the Test Suite (a collection of test cases), or in a Resource file (which is just a collection of keywords). In our example, all of the keywords are User keywords that in turn use Library keywords to make REST API calls to the toaster to perform the tasks. If any of the keywords fail, the test case will fail, and in the resulting report and log file that is generated this can be inspected and understood by both non-technical and technical personnel allowing bugs to be quickly identified.

The other important aspect of the Robot Framework to grok is the use of Variables. Any test case will be subject to change, such as the time we want to wait for toast to be completed, or the number of concurrent toasts we want to make. By using variables, we can write a test once, making it flexible enough to test a range of scenarios. More information on variables can be found here.

Now to sprinkle some words of wisdom I have garnered from using the robot framework.
Follow a style guide. Using a style guide gives your tests structure; you can even enforce a style with a linter such as robotframework-lint. This guide is a good start to form your style guide.
Prefix all keywords with the Library or Resource they originate from - This will help your team members know where User Keywords originate from (as they could be in the test case file, a library or a resource), to better understand them and to troubleshoot issues if need be.
Be consistent with naming and delimiters - As Robot uses a tabular syntax separated by two or more spaces or the pipe character, there’s nothing worse than seeing both mixed, or two space in some spaces and four or more in others. Stick to one and try to enforce it.
Simple folder structure - Now there is no real best way to organise your robot framework test suite, but I would follow something similar to this:

├── libraries
│   └──
├── resources
│   └── toaster.robot
├── tests
│   └── api
│       ├── 00_authentication.robot
│       ├── 01_temperature_control.robot
│       └── __init__.robot
└── variables

I hope that this short blog on the Robot Framework and ATDD has made getting started with the framework a little less daunting. It really is an easy to use and valuable tool. The existing libraries help you automate many of the tasks you would have to do manually, and if you don’t find one that does what you need it to do, it is easy to create using Python or Java. The main thing to remember is to stay organised, use a convention and stick to it; it makes collaboration and troubleshooting a lot easier.

Well, that’s all folks, happy testing!

Originally Published on the [] on 5/20/17.