Skip to content

Using keyword Import Library result in unexpected behaviour #4751

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dries007 opened this issue Apr 26, 2023 · 3 comments
Open

Using keyword Import Library result in unexpected behaviour #4751

dries007 opened this issue Apr 26, 2023 · 3 comments
Milestone

Comments

@dries007
Copy link

I have a situation where 2 test cases would like to import the same library with different arguments.

My library controls the mocking of something and depending on the test case, some component of the system-under-test is present in the mock or not. This is not an issue in other test suites because there the mocked components are static for the while suite. This particular test suite verifies the response to a lack of one or more of the components, so only there the mock is variable. This is why I'd prefer to stick with being able to specify the settings at import time rather than having to add extra keywords to set up the mock.

The problem is that, when using the keyword Import Library as is, the library is imported for the whole suite. The second time the same library is imported, even with different arguments, nothing happens. I think because it ends up with the same name the importer assumes nothing needs to happen.

To make things more confusing, the __init__ of the library actually is called with the given arguments, so my logging indicated that the library was being initialized correctly. It would also help if this was eliminated if the library is not going to be used anyway.

Ideally I'd like library imports to depend on the library scope, that way the library controls itself, but that would probably break comparability with other usecases. At the very least when an import does not actually do anything, I'd like to know about it. If possible a warning if the import arguments differ would already be a huge help. Now as far as I can find, nothing is logged anywhere.

My workaround for now is to import the libraries using WITH NAME and making sure the libraries are inert upon init. This is not ideal as it requires special attention that it counter-intuitive.

To aid in reproduction, I've attached a robot, library, and debug files as a zip:

ImportLibraryIssue.zip

For a quick overview without having to download & unzip:

image

debug.txt

*** Test Cases ***
TC1
    Import Library  TestLibrary     ABC
    Test Argument

TC2
    Import Library  TestLibrary     XYZ
    Test Argument
from robot.api.logger import warn
class TestLibrary:
    def __init__(self, argument):
        warn(f'TestLibrary init with arg={argument!r}')
        self.argument = argument
    def test_argument(self):
        warn(f'TestLibrary test_argument with arg={self.argument!r}')
otemek added a commit to otemek/robotframework that referenced this issue Jun 22, 2023
@otemek
Copy link
Contributor

otemek commented Jun 22, 2023

I have the same case, so put my proposal here #4804

@otemek
Copy link
Contributor

otemek commented Jul 5, 2023

I have the same case, so put my proposal here #4804

I think could have simplified too much and my implementation does not consider other scenarios. Cause sometimes it might be like that we need the same instance and other times we may need a new instance. Maybe some extra parameter for the Import Library keyword like reimport=True/False with the default value, e.g. False, would do the thing? How about that?

@pekkaklarck
Copy link
Member

There are issues with imports and we try to sort them out in RF 8.

@pekkaklarck pekkaklarck added this to the v8.0 milestone May 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants