Support common keyword setup / teardown for a file about robotframework HOT 6 OPEN

@Brownies maybe https://github.com/sebastianciupinski/robotframework-listenerlibrary is what you are looking for

from robotframework.

@Brownies maybe https://github.com/sebastianciupinski/robotframework-listenerlibrary is what you are looking for

If I understood its functionality correctly it's not quite what I'm looking for. I could use Register Start Keyword Listener for every keyword but in that case I might as well use Setup for those keywords and that's what I want to avoid.

from robotframework.

The reason this functionality hasn't been implemented is that we haven't considered it too common for all or even most of the keywords in a same suite or resource file to have a same setup or teardown. Do you @Brownies have a concrete example about such usage? Implementing this shouldn't be too complicated and the design with Keyword Setup and Keyword Teardown settings would also be straightforward.

from robotframework.

This functionality would become more usable if we'd allow changing the default setup/teardown within a file like this:

*** Settings ***
Keyword Setup        Setup 1    # The initial default setup

*** Keywords ***
Keyword 1
    xxx

Keyword 2
    yyy

*** Settings ***
Keyword Setup        Setup 2    # New setup used with the subsequent keywords

*** Keywords ***
Keyword 3
    zzz

Keyword 4
    ååå

The above doesn't currently because default specified in the Settings section apply for the whole file. That's even true if the Settings section is positioned after the test or keyword section it affects. There have now and then been requests to allow changing test related settings (mainly the template), and although they have been rejected earlier I start to like that idea nowadays. The main benefit I see is that it would simplify implementing new parsers for Robot data (e.g. in C or Rust for performance), because a setting like Test Template at the end of the file wouldn't anymore affect how earlier data should have been parsed.

Although the above is somewhat related to this issue, it absolutely would need a separate issue. Changing the behavior would also be somewhat badly backwards incompatible, so it would need a deprecation period. I may submit an issue about that at some point, but others can submit one already now if you find it important.

from robotframework.

Somewhat simplified example is that I have a resource file with a bunch of keywords for a REST API. I want the keywords to be independent in the sense that if the default credentials are good for what I'm doing, then all I need to do in a test file is to import the resource file and call the keyword. I want to use a single RequestsLibrary session per credential set if possible because I don't want to get hundreds of access tokens per test run. So I end up calling Get Token And Create Session as the first step of every keyword in this file.

Note, we haven't actually upgraded to RF 7 yet so there's no [Setup] sections in the keywords.

*** Settings ***
Library         RequestsLibrary

*** Keywords ***
Get Token And Create Session
    [Arguments]    ${session_alias}    ${username}    ${password}
    ${session_exists} =    Session Exists    ${session_alias}
    IF    not $session_exists
        ${data} =    Create Dictionary    username=${username}    password=${password}
        ${response} =    Post    ${REST_V1_BASE_URL}/token    json=${data}
        ${headers} =    Create Dictionary    Authorization=${response.json()}[accessToken]    Accept=application/json
        Create Session    ${session_alias}    ${REST_V1_BASE_URL}    headers=${headers}    verify=True
    END

Get Stuff
    [Arguments]    ${stuff_id}    ${session_alias}=v1    ${username}=${REST_USERNAME}    ${password}=${REST_PASSWORD}
    Get Token And Create Session    ${session_alias}    ${username}    ${password}
    ${response} =    Get On Session     ${session_alias}    /stuff/${stuff_id}
    RETURN    ${response.json()}

Post Stuff
    [Arguments]    ${stuff}    ${session_alias}=v1    ${username}=${REST_USERNAME}    ${password}=${REST_PASSWORD}
    Get Token And Create Session    ${session_alias}    ${username}    ${password}
    ${response} =    Post On Session     ${session_alias}    /stuff    data=${stuff}
    RETURN    ${response.json()}[stuffId]
    
# And so on...

from robotframework.

Do you ... have a concrete example about such usage?

I have.

I have templated testcases - something like this;

*** Settings ***
Resource        ${CURDIR}/../resources/landingPage_test_templates.resource
Suite Setup     Open And Setup New Browser   ${DEFAULT_BROWSER}   ${IS_HEADLESS}

*** Test Cases ***
Language Selection
  [Template]   Language Selection Template
  fi   en
  sv   fi
  en   sv

So, each test case is actually defined as Keyword and some of the arguments are going to a test setup, i can't use [Setup] and [Teardown] on this file where test cases are defined (?) as variable is not yet defined at this point (as its end up as argument for keyword) so the workaround is to use setup and teardown for the keyword like this;

*** Keywords ***
Language Selection Template
  [Documentation]   Verifies language change from/to
  ...
  ...   Args:
  ...   ${lang}:  langugage to change to 
  ...   ${locale}:  browser locale.
  [Arguments]   ${lang}   ${locale}
  [Setup]   Navigate To   ${LANDINGPAGE_BASEURL}   fi   ${DEFAULT_BROWSER}   ${IS_HEADLESS}   ${locale}
  # my testcse here .. 
  [Teardown]   Tear Down Test Case

Since i have bunch of test templates and only test templates within this file, it would be quite useful for having something like Keyword Setup and Keyword Teardown in settings section if the argument is evaluated at the keyword scope.

from robotframework.