Support common keyword setup / teardown for a file

[Brownies]

Basically what the user guide says isn't supported at the moment. Something like Keyword Setup/Keyword Teardown settings for resource files to set setup/teardown steps for all keywords, which you could then override with individual Setup/Teardown settings in keywords, much like Test Setup and Setup for tests.

My use case is simplifying some bits of session management for RequestsLibrary keywords. I realize this is just syntax sugar and very much a "nice to have", rather than a need or a requirement.

[sebastianciupinski]

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

[Brownies]

@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.

[pekkaklarck]

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.

[pekkaklarck]

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.

[Brownies]

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...