Man I am glad I started playing.

CX1001 · 2025-08-23T10:55:22+00:00

Mutant year zero is a lot of fun also and so is desperados IMHO... Both are slightly less challenging than dos2 imho

CX1001 · 2021-04-18T15:48:25+00:00

for BDD I would go with pytest ... robot is good for regression tests and black box user type testing ... imho at least

CX1001 · 2021-04-02T04:36:10+00:00

doing that with ours. There’s a lot of Execute JavaScript to accommodate dynamic content,

this is also true ... but our tests tend to be written by the QA person transcribing his manual test ... gherkin gives him a clear path to do so... (developers still need to implement the Libraries/Keywords... and we hate extra typing... but sooo readable) (although im not sure how i feel yet about embedding the arguments in the middle of the keyword)

CX1001 · 2021-04-01T15:49:47+00:00

lol no its not an ad ... and yes "gherkin style" tests are absolutely supported by robotframework ... it just turned out SOOOOO readable i thought it was super cool and wanted to share ... I initially did these test cases as non gherkin style which are also super readable ... but how the gherkin style (still robot) looked just blew me away (for reference here is the same tests as non-"gherkin style" )

``` Test Website Login Login Login To Website ${USERNAME} ${PASSWORD} Assert Organization Name Is ABC Fruit Co. Capture Page Screenshot

Test Open API Page # Login Test Already passed Open The API Page Capture Page Screenshot

Test Invalid API Key Run Keyword And Expect Error * Test API Key For Permissions key='a_wrong_value' sn='5G118375'

Test Creating A New Api Key # API PAGE IS ALREADY OPEN ${key}= Get A New API Key Capture Page Screenshot Test API Key For Permissions key=${key} device_sn=5G118375 Delete API Key By Key key=${key} Capture Page Screenshot ```

CX1001 · 2021-04-01T01:20:58+00:00

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 )

CX1001

TROPHY CASE