Tom Purl's Blog

robotframework

This post was originally published on 2019-10-17

Overview

The first thing I always try to do to learn a new language after writing “hello world” is implementing fizzbuzz. This wasn’t true with the Robot Framework, so I thought I would be time to give it a try.

My Implementation

 *** Settings ***
 Documentation    Fizzbuzz kata
 Library    BuiltIn

 *** Test Cases ***

 Print Fizzbuzz
     [Documentation]    Print the numbers 1-100 in the log.html file, replacing
     ...                all numbers that are divisible by 3 with "fizz", 5 with
     ...                "buzz", and if divisible by both "fizzbuzz".

     Fizzbuzz

 *** Keywords ***

 Fizzbuzz
     FOR    ${number}    IN RANGE    1    101
         ${divisible_by_3}=    Is Mod Zero    ${number}    3
         ${divisible_by_5}=    Is Mod Zero    ${number}    5
         ${divisible_by_15}=   Is Mod Zero    ${number}   15
         Run keyword if    ${divisible_by_15}    Log to Console    FIZZBUZZ
         ...    ELSE IF    ${divisible_by_3}     Log to Console    FIZZ
         ...    ELSE IF    ${divisible_by_5}     Log to Console    BUZZ
         ...    ELSE    Log to Console    ${number}
     END

 Is Mod Zero
     [Documentation]    Returns whether the modulus of two numbers is zero.
     [Arguments]        ${dividend}    ${divisor}
     [Return]           ${is_modulus_zero}
     # Go-go gadget Python!
     ${is_modulus_zero}=    Evaluate    divmod(${dividend},${divisor})[1] == 0

Observations

The first thing I learned from this exercise was how surprisingly difficult it was to evaluate the result of an expression. If I was running this in Python I would do something like this:

for num in range(1, 101):
    if num % 15 == 0:
        print("fizzbuzz")
    elif num % 3 == 0:
        print("fizz")
    elif num % 5 == 0:
        print("buzz")
    else:
        print(num)

I can evaluate the num % 3 part within the else statement using Python. But here’s what I can’t do using the Robot Framework:

Run keyword if    Is Mod Zero    ${number}    15   Log to Console    FIZZBUZZ
...    ELSE IF    Run keyword and return status    Is Mod Zero    ${number}    3     Log to Console    FIZZ

I’m sure something like this is possible without creating a temporary variable (and evaluating the Is Mod Zero 3 times every time) but I’m not quite sure what it is.

The second thing I learned was how easy it was to run a Python one-liner from Robot. If that didn’t work then I simply didn’t see how I was going to evaluate a modulus from Robot without writing a Python module (for a one-liner).

Tags: #robotframework, #programming

This post was initially posted on 4/14/2020

A co-worker of mine recently asked me why I prefer to write automated REST API tests using the Robot Framework. Specifically, he couldn’t understand why I didn’t just automate everything using Postman, which is a very popular way of doing such things.

I was a little surprised by what I told him and thought that this may help other so I here’s my rationale. If I’m wrong I’m sure someone will let me know :–)

  1. Postman doesn’t really support the idea of a “setup” and “teardown” functions. The closest analogues are “pre-request scripts” and “Tests”. These are good at a request level, but a test case is often larger than just one request. I’m a huge fan of how Robot Framework handles test case and suite-level setup and teardown functionality and how you can configure it as an annotation.

  2. Code that you write in the “pre-request scripts” and “tests” sections can’t easily be modularized into external libraries. So for example, if each request requires you to run 10 lines of JS as a pre-request script, then you’re copying and pasting that JS into each and every request. If you need to make a change to that JS, then you need to copy and paste the new JS into each request. This makes things very difficult to maintain.

  3. It’s difficult to follow the workflows of a Postman test suite. Let’s say that you want to run request #1 before you run request #2, and if everything works then run request #3. Then let’s say that you want to run request #4, then 2 and 3. I’ve seen examples on how to do this but it’s very, very kludgy and I wouldn’t want to maintain those scripts or follow that bouncing ball.

  4. The response I’ve seen to #3 is that you just simplify your test cases as much as possible and then put everything else you test needs to do in JS. But then that takes us back to #2.

So what is Postman good for? To me, the killer feature of Postman is that you can “kick the tires” of your API and then write your test using a single tool that is nearly ubiquitous. And I agree that Postman is by far the best tool I’ve found for quickly poking and prodding a REST API.

So I guess what I’m saying is, when it comes to prototyping REST calls, Postman is hard to beat. However, if I want to actually write a formal test suite that is easy to read, write, and maintain, I would much rather use a “real” programming language bundled with a good test runner (both of which are included in the Robot Framework).


Tags: #postman, #robotframework, #testing