I'd like to refactor some of our tests. We have an interesting
phenomenon that some tests don't run, when the whole suite (directory)
is executed (at some point the browser window does not close, despite
a call to "Close All Browsers"). Since the all use the
SeleniumLibrary, but import that in different ways, I suspect that
inconsisten and/or multiple initialization could be the problem.
From the user guide, I took:
a) It is possible to import test libraries in test case files,
resource files and test suite initialization files. In all these
cases, all the keywords in the imported library are available in that
file. With resource files, those keywords are also available in other
files using them.
b) The library name is got normally from the module or class name
implementing it, but there are some situations where changing it is
desirable: There is a need to import the same library several times
with different arguments. This is not possible otherwise.
My first attempt was to import SeleniumLibrary in an __init__.txt:
Include the Library with the correct settings, and call Teardown
Selenium on Test Teardown (custom keyword that takes screenshot when
test fails, and closes window). And also call "Close All Browsers" on
Suite Teardown. I also removed all other imports from other resources
and test case files. Well, that didn't work, because of a).
On the otherhand, I have not had problems when SeleniumLibrary was
imported in a resource file AND also in a test case file. But I am
wondering what is happening then with the parameters, that you pass to
the SeleniumLibrary. Do they overwrite each other? Who is winning?
What would your strategy be to deal with this? Sorry that this problem
report is still a little fuzzy, I'm still in the process of
understanding the problem :)
Andreas
c) The user keywords and variables defined in a resource file are
available in the file that takes that resource file into use.
Similarly available are also all keywords and variables from the
libraries, resource files and variable files imported by the said
resource file.
If I understand that correctly, I can have a test case, that uses
resource file R-A. Resource file R-A uses resource file R-B and
library L-B. All keywords from R-B and L-B are available in the test
case, right? Are you sure this is the case?
Andreas
On Apr 14, 9:29 pm, AndreasEK <Andreas.Ebb...@gmx.de> wrote:
> case, right? Are you sure this is the case?
Nevermind. Typo in the test case :(
Andreas
There are two related concepts here:
First is the higher level suite setup, which you already discovered,
and which has to be used in test case directory's __init__ -file.
The other is sharing the imports. This can only be done via resource
files. So, if you want to guarantee that you use the same library in
all suites, the library should be taken into use in a resource file,
and that resource file is imported by the __init__ -file and the
actual test case files.
There's also a third bit of information. described in [1], which
combined with the fact that SeleniumLibrary's scope is global, means
that even if you take SeleniumLibrary into use many times with same
arguments, the actual instance will always be same.
hth,
__janne
On Apr 15, 7:14 am, Janne Härkönen <janne.t.harko...@gmail.com> wrote:
> First is the higher level suite setup, which you already discovered,
> and which has to be used in test case directory's __init__ -file.
>
> The other is sharing the imports. This can only be done via resource
> files. So, if you want to guarantee that you use the same library in
> all suites, the library should be taken into use in a resource file,
> and that resource file is imported by the __init__ -file and the
> actual test case files.
Hm, interesting. You say, that the __init__ file AND the test case
file should import the resource file. For my understanding, this is
* so that the __init__ file defines which parameters should be used to
initialize the library
* so that the keywords are available in the test case, if the
parameters deviate from the ones used in the __init__ file, I assume
there will be an error message?
> There's also a third bit of information. described in [1], which
> combined with the fact that SeleniumLibrary's scope is global, means
> that even if you take SeleniumLibrary into use many times with same
> arguments, the actual instance will always be same.
I knew about the scope, but I could not find it in the documentation
of the Selenium Library. I think that's a useful bit of information
that should be in there. (And if it's in there, it should be more
prominent :)
Looking at the source for the SeleniumLibrary I found the
ROBOT_LIBRARY_SCOPE = 'GLOBAL'.
Thanks,
Andreas
Are you talking about __init__.py in SeleniumLibrary or __init__.txt
(or __init__.html or __init__.tsv) used by Robot Framework? The
__init__.py file has SeleniumLibrary class and its __init__ method
defines parameters that the library accepts. RF's __init__.txt files
are used to set settings such as Documention and Suite Setup for test
suites created from directories. No keyword or variables imported or
otherwise created in __init__.txt files are automatically available to
lower level suites.
> * so that the keywords are available in the test case, if the
> parameters deviate from the ones used in the __init__ file, I assume
> there will be an error message?
Yes, taking a library into use with wrong parameters fails.
>> There's also a third bit of information. described in [1], which
>> combined with the fact that SeleniumLibrary's scope is global, means
>> that even if you take SeleniumLibrary into use many times with same
>> arguments, the actual instance will always be same.
Notice also that if you take the library into use with different
parameters on a different suite, you will get different instance there
regardless the scope.
> I knew about the scope, but I could not find it in the documentation
> of the Selenium Library. I think that's a useful bit of information
> that should be in there. (And if it's in there, it should be more
> prominent :)
True, libdoc.py should write this information to the documentation it
generates. Please submit an enhancement request about it.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
On Apr 15, 10:51 am, Pekka Klärck <pekka.kla...@gmail.com> wrote:
> 2010/4/15 AndreasEK <Andreas.Ebb...@gmx.de>:
>
> > On Apr 15, 7:14 am, Janne Härkönen <janne.t.harko...@gmail.com> wrote:
>
> >> First is the higher level suite setup, which you already discovered,
> >> and which has to be used in test case directory's __init__ -file.
>
> >> The other is sharing the imports. This can only be done via resource
> >> files. So, if you want to guarantee that you use the same library in
> >> all suites, the library should be taken into use in a resource file,
> >> and that resource file is imported by the __init__ -file and the
> >> actual test case files.
>
> > Hm, interesting. You say, that the __init__ file AND the test case
> > file should import the resource file. For my understanding, this is
> > * so that the __init__ file defines which parameters should be used to
> > initialize the library
>
> Are you talking about __init__.py in SeleniumLibrary or __init__.txt
> (or __init__.html or __init__.tsv) used by Robot Framework?
The latter.
> RF's __init__.txt files
> are used to set settings such as Documention and Suite Setup for test
> suites created from directories. No keyword or variables imported or
> otherwise created in __init__.txt files are automatically available to
> lower level suites.
not automatically means that there's a way to achieve that?
The way I understood Janne is that I should import the Library in a
Resource file, which then has to be imported in the __init__.txt and
all test cases.
> > * so that the keywords are available in the test case, if the
> > parameters deviate from the ones used in the __init__ file, I assume
> > there will be an error message?
>
> Yes, taking a library into use with wrong parameters fails.
Well, what does wrong parameters mean? For example, I could do:
in __init__.txt
Library SeleniumLibrary 1m 192.168.30.30 3333
And in a test case (in the directory that is initialized with
__init__.txt above)
Library SeleniumLibrary 2s localhost 4444
I could just try it, but now I'm asking. Will that generate an error
at runtime?
> Notice also that if you take the library into use with different
> parameters on a different suite, you will get different instance there
> regardless the scope.
Things are getting complicated :)
> True, libdoc.py should write this information to the documentation it
> generates. Please submit an enhancement request about it.
http://code.google.com/p/robotframework/issues/detail?id=533
Andreas
This is the only way to have imports in one place.
>> > * so that the keywords are available in the test case, if the
>> > parameters deviate from the ones used in the __init__ file, I assume
>> > there will be an error message?
>>
>> Yes, taking a library into use with wrong parameters fails.
>
> Well, what does wrong parameters mean? For example, I could do:
>
> in __init__.txt
>
> Library SeleniumLibrary 1m 192.168.30.30 3333
>
> And in a test case (in the directory that is initialized with
> __init__.txt above)
>
> Library SeleniumLibrary 2s localhost 4444
>
> I could just try it, but now I'm asking. Will that generate an error
> at runtime?
There shouldn't be errors in this case. You can use different
arguments when you take the library into use. What I meant with wrong
arguments was doing something linke `Library SeleniumLibrary invalid
args here`.
>> Notice also that if you take the library into use with different
>> parameters on a different suite, you will get different instance there
>> regardless the scope.
>
> Things are getting complicated :)
This is actually the exact same case you illustrated above.
>> True, libdoc.py should write this information to the documentation it
>> generates. Please submit an enhancement request about it.
>
> http://code.google.com/p/robotframework/issues/detail?id=533
Thanks. I can probably implement that already today. I have some
libdoc.py style enhancements to do also.
On Apr 15, 12:23 pm, Pekka Klärck <pekka.kla...@gmail.com> wrote:
> 2010/4/15 AndreasEK <Andreas.Ebb...@gmx.de>:
>
> > On Apr 15, 10:51 am, Pekka Klärck <pekka.kla...@gmail.com> wrote:
>
> >> > * so that the keywords are available in the test case, if the
> >> > parameters deviate from the ones used in the __init__ file, I assume
> >> > there will be an error message?
>
> >> Yes, taking a library into use with wrong parameters fails.
>
> > Well, what does wrong parameters mean? For example, I could do:
>
> > in __init__.txt
>
> > Library SeleniumLibrary 1m 192.168.30.30 3333
>
> > And in a test case (in the directory that is initialized with
> > __init__.txt above)
>
> > Library SeleniumLibrary 2s localhost 4444
>
[...]
>
> >> Notice also that if you take the library into use with different
> >> parameters on a different suite, you will get different instance there
> >> regardless the scope.
>
> > Things are getting complicated :)
>
> This is actually the exact same case you illustrated above.
So if I don't pay attention to the parameters, with which a Library is
initialized, I might end up with two instances of a library in a
single test case, even if the Library is scoped GLOBAL. Correct?
Andreas
That's correct. It would be pretty hard to use the same instance when
the library is initialized with different arguments.
On Apr 15, 2:48 pm, Pekka Klärck <pekka.kla...@gmail.com> wrote:
> > So if I don't pay attention to the parameters, with which a Library is
> > initialized, I might end up with two instances of a library in a
> > single test case, even if the Library is scoped GLOBAL. Correct?
>
> That's correct. It would be pretty hard to use the same instance when
> the library is initialized with different arguments.
Thanks for your patience and help!
Andreas