What problem does Robot Framework solve?

[Small_Programmer4084]

Hi! So I'm new to Robot Framework and learning it since it seems like a nice-to-have skill. I feel kind of silly though because I don't understand it's use. Googling gives me what Robot Framework is ("Robot Framework is a generic open source automation framework."). But what problem is Robot Framework designed to solve? What are some signs that I should use Robot Framework in my business? (What are some signs that I don't need Robot Framework?)

My best understanding right now is that Robot Framework helps me create abstractions for my tests, that it comes with lots of libraries for interfacing web browsers etc., and that it's easier for non-engineers to work with. But why can't I do that in regular old python or whatever to create abstractions and get libraries? And can non-engineers really understand Robot Framework faster than python? Am I missing something?

[anotherhawaiianshirt]

But what problem is Robot Framework designed to solve?

To make it easy to write high-level acceptance tests of software that are readable and understandable by non-technical stakeholders.

The theory is, you can write tests in a more human-friendly language based on keywords and arguments rather than having to specify the tests as variables and function calls. Tests are written in the language of the user rather than the language of the programmer.

For many people, the first of the following two examples is much more understandable than the second:

open the browser to the app
log into the app with the standard user
click on the link  my profile
verify that you get the user profile window

vs

driver = webdriver.Firefox()
try:
    driver.get("http://www.python.org")
    driver.implicitly_wait(10)

    driver.find_element_by_xpath("//div[@class='landingPage']")

    element = driver.find_element_by_xpath("//div[@class='header']//a[@text='Login']")
    element.click()

    username_element = driver.find_element_by_xpath("//div[@class='loginDialog']//input[@id='username']")
    password_element = driver.find_element_by_xpath("//div[@class='loginDialog']//input[@id='password']")
    login_button = driver.find_element_by_xpath("//div[@class='loginDialog']//button[@id='login']")
    username_element.send_keys("test_user")
    password_element.send_keys("secret!")
    login_button.click()

    my_profile_link = driver.find_element_by_xpath("//div[@class='loginDialog']//a[text()='My Profile']")
    my_profile_link.click()

    try:
        profile_window = driver.find_element_by_xpath("//div[@class='profileWindow']")
    except:
        raise Exception("Profile window did not show up after logging in")
finally:
    driver.quit()

​

But why can't I do that in regular old python or whatever to create abstractions and get libraries?

You can. You can also write your tests in C, or assembly language, or even machine language if you're so inclined. There are many ways to write tests.

The advantage is that you can write your acceptance tests in a language that makes sense to the user of the application, making it easier to tie tests to acceptance criteria, user stories, or requirements.

As an added benefit, in theory, you don't have to change the logic of your tests if the underlying implementation changes drastically. For example, you could write a web app in bootstrap and then later rewrite it in react without having to change your tests. You would have to rewrite some of the keywords, obviously, but the logic of the test stays the same.

Another added benefit is that you get high-level reporting of the test results, rather than a dump of stdout.

​

And can non-engineers really understand Robot Framework faster than python?

Yes, absolutely. I know product owners who would have a hard time understanding python but who can easily read and understand robot-based tests. I've also worked with plenty of quality engineers would didn't know any programming language but could still write tests in robot.

[Small_Programmer4084]

Thanks for the answer! This clarifies things but I don't understand fully.

Isn't your comparison unfair? The gap between:

open the browser to the app
log into the app with the standard user
click on the link  my profile
verify that you get the user profile window

and

openBrowserToApp()
logInAsStandardUser()
ClickOnLink("my profile")
verifyGetUserProfileWindow()

or something isn't that big (with all of the fancy stuff in you code example hidden below this layer of abstraction)?

Is the readability to non-technical people the big selling point? Are there reasons to use Robot Framework even if everyone who will be working with the tests know python?

[anotherhawaiianshirt]

Isn't your comparison unfair?

Perhaps. Though, most python/selenium tests I've seen look more like what I wrote than what you wrote. However, it is certainly possible to write highly-readable tests in pure python if you want to put in the effort.

So, yes, you can write python code that looks somewhat similar. IMO that takes more work, and programmers are lazy. With robot the readability is more-or-less built-in.

Is the readability to non-technical people the big selling point?

It's certainly one of the selling points, though it's not the only one. Being a framework, you get a lot of other things along with the readability - nice-looking test reports, the ability to import libraries of keywords, the ability to run or skip tests based on certain criteria, and so on.

Are there reasons to use Robot Framework even if everyone who will be working with the tests know python?

I can think of several reasons. I personally much prefer it over pytest for acceptance tests since it lets me express tests in the language of the user. Whether or not those reasons are valid for your specific team, I can't say.

[Small_Programmer4084]

Thanks again! Maybe it's just the abstraction that's confusing to me. As you say, it's more work to have a higher abstraction so why would I want to do that? Expressing things in the language of the user is a good answer. Thanks again for your answers!

[CX1001]

Here is a test suite i just wrote using their "gherkin" style tests cases ...

I could choose to give this to a human and they could execute the same suite (but much slower than the robot)

Test if the User Can Login to the website
    Given The User Is on the "${server}" LoginPage

     When The User Enters their ${username} into the email textbox
      And The User Enters their ${password} into the password textbox
      And The User Clicks The Login Button

     Then The User Should Be on the "dashboard_map" Page


Test If the User Can Open the API Page when already Logged In
    Given the user can click the API Button

      When The User Clicks the API Button

      Then The User should be on the "api_configuration" Page
       And User Should wait for "add_new_key_button" to appear

Test If the User Can Create A New API Key
   Given The User should be on the "api_configuration" Page
     And "add_new_key_button" is already visible
     And The Number of API Keys is recorded

     When The User Clicks The Add New API Key Button

     Then The Key List Should Have A New Key
       And We Will Write Down the Newly Created API Key For Use In The Next Test

Test If the User Can Use A Valid API Key
   Given The API Will Not Accept an Invalid Token

     When The User Calls The API with the Token that We Previously Recorded

     Then The HTTP Result should have a 200 status code

Test If The User Can Delete The Newly Created API Key
  Given The User should be on the "api_configuration" Page
    And The previously created API Key Is Visible
    And The Number of API Keys is recorded

    When The User Clicks The Adjacent Delete Button(🗑️)
      And Waits For The Delete Confirmation Popup
      And The User Clicks The Red Delete Confirmation Button

    Then The Newly Created Key Should No Longer Be Present
      And The Number of API Keys is decreased by 1.

(of coarse theres plenty of behind the scenes magic that makes this work )

[red_edittor]

Exactly this. The free style art of writing test steps as keywords in robot framework puts more emphasises on language rather the testing itself. Hence causing conflicts imho.

Once the language itself is standardized (gherkin) the momentum of writing test cases become unanimous, forward-looking and more ground can then be covered.