You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
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:
debug.txt
The text was updated successfully, but these errors were encountered: