[QUESTION] What is the best practice of handling RobotFramework libraries with complex __init__ functions

[MikeAckerschott]

Please describe.
Im currently working in a codebase in which we use python files as robotframework libraries within robottests. Our codebase is quite big and complex, and i assumed that was one of the reasons why RobotCodes analysis was quite slow, but i didnt experience this slowness in different projects. After some trial and error i found out that by default, RobotCode's analyse function runs the __init__ function of imported libraries. This means that a project with the following 2 files:

*** Settings ***
Library    main.ExampleLibrary

*** Test Cases ***
Example test
    Log To Console  message=Hello, World!

import time
from robot.api.deco import keyword

class ExampleLibrary:
    ''' Does some complex stuff in the init function'''
    
    def __init__(self):
        time.sleep(100)

will in fact take 100 seconds to return the RobotCode analysis result. Now I'm unsure whether this is intended, but if it is, what would be the best practice to avoid these type of situations? Should libraries expose a keyword that handles complex initialization to avoid excessive runtime duration of the RobotCode analyse function? Thanks

Desktop (please complete the following information):

• VS Code Version [e.g. 1.117.0]
• RobotCode Version [2.5.1]
• OS: [Windows 11]
• Python Version [3.11.9]
• RobotFramework Version [7.4.2]
• robocop Version [8.2.7]

[d-biehl]

Hi, yes, this is expected.

RobotCode needs to load and instantiate Robot Framework libraries to get their
keywords, arguments, documentation, types, etc. For class based libraries this
means that __init__ is executed during analysis. This is basically the same
kind of thing tools like Libdoc need to do as well: inspect the library without
actually running a test.

So the short answer is: try to keep __init__ cheap.

A Library import should make the library available to Robot Framework. It
should not already start the actual test environment. Things like connecting to
a server, opening a browser, connecting to a device, starting services, or
waiting for external systems usually belong into a suite setup, test setup,
keyword setup, or lazy initialization during keyword execution — not into the
library constructor.

In my opinion a constructor should usually only bring the object into a valid
initial state. For example, it can store arguments, initialize internal state,
set defaults, prepare caches, etc. But it should avoid expensive or blocking
work.

A usual pattern is to do the expensive stuff lazily:

from robot.api.deco import keyword


class ExampleLibrary:
    ROBOT_LIBRARY_SCOPE = "SUITE"

    def __init__(self):
        self._client = None

    @property
    def client(self):
        if self._client is None:
            self._client = create_expensive_client()
            self._client.connect()
        return self._client

    @keyword
    def do_something(self):
        return self.client.do_something()

If the resource should be cleaned up automatically when the library instance is
released, weakref.finalize can be a nice lightweight option:

import weakref
from robot.api.deco import keyword


def _disconnect_client(client):
    client.disconnect()


class ExampleLibrary:
    ROBOT_LIBRARY_SCOPE = "SUITE"

    def __init__(self):
        self._client = None
        self._client_finalizer = None

    @property
    def client(self):
        if self._client is None:
            client = create_expensive_client()
            client.connect()

            self._client = client
            self._client_finalizer = weakref.finalize(
                self,
                _disconnect_client,
                client,
            )

        return self._client

    @keyword
    def do_something(self):
        return self.client.do_something()

Just be careful not to register a bound method like this:

weakref.finalize(self, self.disconnect_client)

because that keeps a reference to self and prevents the library instance from
being garbage collected.

If users should control the lifecycle explicitly, I would expose matching setup
and teardown keywords and use them from Robot Framework:

from robot.api.deco import keyword


class ExampleLibrary:
    ROBOT_LIBRARY_SCOPE = "SUITE"

    def __init__(self):
        self._client = None

    @keyword
    def connect_to_server(self):
        if self._client is None:
            self._client = create_expensive_client()
            self._client.connect()

    @keyword
    def disconnect_from_server(self):
        if self._client is not None:
            self._client.disconnect()
            self._client = None

    @keyword
    def do_something(self):
        if self._client is None:
            raise RuntimeError("Not connected. Call `Connect To Server` first.")
        return self._client.do_something()

*** Settings ***
Library           ExampleLibrary
Suite Setup       Connect To Server
Suite Teardown    Disconnect From Server

For simple expensive values that do not need cleanup, functools.cached_property
can also be useful:

from functools import cached_property
from robot.api.deco import keyword


class ExampleLibrary:
    @cached_property
    def expensive_data(self):
        return load_expensive_data()

    @keyword
    def do_something(self):
        return process(self.expensive_data)

Robot Framework also has BuiltIn().robot_running and
BuiltIn().dry_run_active, which can be used if something really should only
happen during actual Robot Framework execution and not when the library is loaded
by RobotCode, Libdoc, or similar tools:

from robot.libraries.BuiltIn import BuiltIn


class ExampleLibrary:
    def __init__(self):
        self._client = None

        builtin = BuiltIn()
        if builtin.robot_running and not builtin.dry_run_active:
            self._client = create_expensive_client()
            self._client.connect()

See:
https://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#detecting-is-robot-framework-running

But I would still not use that as the main fix for expensive constructors. In
most cases I would move the expensive setup out of __init__ completely and put
it into the proper Robot Framework lifecycle: suite setup, test setup, keyword
execution, lazy initialization, or a matching teardown/cleanup mechanism.

So yes, RobotCode executing __init__ here is expected. The part I would change
is the library design: importing a library should be cheap; connecting to the
system under test should happen when the test actually starts using it.

[MikeAckerschott]

Thanks for the detailed reponse! I do agree, the constructor should only construct the object and make it ready to use. Ive noticed running the robotcode analyze cli within our pipeline takes about 20 minutes for 385 files as of right now, while robocop takes 4 seconds, so something is definitely some logic while its not supposed to during the robotcode analysis. Would you have any tips on finding out which libraries's init function takes the most runtime to execute during the robotcode analysis? This way i can find out and minimally fix it using the if builtin.robot_running and not builtin.dry_run_active: solution you provided. Then when i have time i could refactor the library alltogether