Initialization files not including Resource?

[anirudh dutt]

We have several tests with a Settings table that contains an include for resource files, like:
***Settings***
Resource    ../../../../../Core-Flows/Master_Test_Flow.txt

The "../" parts have to be modified depending on the depth/level of the Test file.

I created an initialization file __init__.txt in the same directory, added that line to the file and commented it out from the Test files in that directory. So the include path is the same (verified and no error messages in dry run). However, the resource file does not get included and the dry-run error log gives "No keyword with name 'XYZ' found." , where XYZ is every user-keyword defined.

The documentation (here http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html?r=2.7.3#initialization-files) does not mention 'Resource' as a valid or invalid setting - so which is it? It would be convenient to have folder-(test suite-) level resources be able to be defined in __init__ files.

Btw, if I explicitly include the init file from the Test using:
***Settings***
Resource    __init__.txt

Then the "Resource" lines in __init__ work as if it were a normal resource-including file. Using this structure would mean adding a similar line with variable path in the first use above, in every Test file.

Is there a way to include resource files at the directory level (so that it applies to lower levels also) ?

One possible work around was to assign the absolute path to a variable in __init__ at the top level so that it can be used as:
Resource    ${ABS_PATH}/__init__.txt
# OR
Resource    ${ABS_PATH}/resources.txt
(in every file so that it's always the correct path at runtime.) Still need to see how to get the absolute path or pass it in.

Suggestions?

- Anirudh

[Pekka Klärck]

2012/10/3 anirudh dutt <ane...@gmail.com>:

>
> Is there a way to include resource files at the directory level (so that it
> applies to lower levels also) ?

No. Keywords and variables created or imported in init files are not
visible for lower level test suites.

> One possible work around was to assign the absolute path to a variable in
> __init__ at the top level so that it can be used as:
> Resource ${ABS_PATH}/__init__.txt

Are you trying to use an init file as a resource? That should not be
possible. If it actually works, you cannot count on it working in the
future.

> # OR
> Resource ${ABS_PATH}/resources.txt
> (in every file so that it's always the correct path at runtime.) Still need
> to see how to get the absolute path or pass it in.

Using an absolute path like this ought to work fine. Alternatively you
could putting your common resource file into a location that is in
PYTHONPATH and then importing it just with the file name (e.g.
`Resource resources.txt`). For some more details see the User Guide
section about taking resource files into use:
http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html#taking-resource-files-into-use

Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[anirudh dutt]

On 5 October 2012 17:17, Pekka Klärck <pe...@iki.fi> wrote:

2012/10/3 anirudh dutt <ane...@gmail.com>:

>
> Is there a way to include resource files at the directory level (so that it
> applies to lower levels also) ?

No. Keywords and variables created or imported in init files are not
visible for lower level test suites.

Okay. So then that includes Resources also. I would raise an enhancement request to enable that but I suspect this is by design, so it would be rejected anyway :-)

> One possible work around was to assign the absolute path to a variable in
> __init__ at the top level so that it can be used as:
> Resource    ${ABS_PATH}/__init__.txt

Are you trying to use an init file as a resource? That should not be
possible. If it actually works, you cannot count on it working in the
future.

Yes, an as explicit call using the Resource setting which seems to work. Will stop doing that.

> # OR
> Resource    ${ABS_PATH}/resources.txt
> (in every file so that it's always the correct path at runtime.) Still need
> to see how to get the absolute path or pass it in.

Using an absolute path like this ought to work fine. Alternatively you
could putting your common resource file into a location that is in
PYTHONPATH and then importing it just with the file name (e.g.
`Resource    resources.txt`). For some more details see the User Guide
section about taking resource files into use:
http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html#taking-resource-files-into-use

Okay, will do that. I guess it could set/append the python path to include the resource folder in the py script that calls pybot to run the tests. This would of course, be a workaround to not being able to define directory-level resources, instead of having to repeat it in every test like in the OP. Another way without touching the path could be to define the ${ABS_PATH} path to be used using the `get_variables()` function.

Thanks, will post which workaround I end up using, if at all.
- Anirudh

[Pekka Klärck]

2012/10/5 anirudh dutt <ane...@gmail.com>:

> On 5 October 2012 17:17, Pekka Klärck <pe...@iki.fi> wrote:
>>
>> 2012/10/3 anirudh dutt <ane...@gmail.com>:
>> >
>> > Is there a way to include resource files at the directory level (so that
>> > it applies to lower levels also) ?
>>
>> No. Keywords and variables created or imported in init files are not
>> visible for lower level test suites.
>>
>
> Okay. So then that includes Resources also. I would raise an enhancement
> request to enable that but I suspect this is by design, so it would be
> rejected anyway :-)

It was an early design decision to make imports explicit. The problem
with keywords/variables from init files being visible to lower level
suites automatically would be that you could easily get name
collisions. Making the change now would be massively backwards
incompatible.

>> > One possible work around was to assign the absolute path to a variable
>> > in
>> > __init__ at the top level so that it can be used as:
>> > Resource ${ABS_PATH}/__init__.txt
>>
>> Are you trying to use an init file as a resource? That should not be
>> possible. If it actually works, you cannot count on it working in the
>> future.
>
> Yes, an as explicit call using the Resource setting which seems to work.
> Will stop doing that.

I had never thought about this possibility. Need to think should this
be explicitly allowed (i.e. documented in the User Guide) or
disallowed (i.e. making it impossible to use init files as resources).
Do others feel strongly about one way or another?

>> > # OR
>> > Resource ${ABS_PATH}/resources.txt
>> > (in every file so that it's always the correct path at runtime.) Still
>> > need
>> > to see how to get the absolute path or pass it in.
>>
>> Using an absolute path like this ought to work fine. Alternatively you
>> could putting your common resource file into a location that is in
>> PYTHONPATH and then importing it just with the file name (e.g.
>> `Resource resources.txt`). For some more details see the User Guide
>> section about taking resource files into use:
>>
>> http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html#taking-resource-files-into-use
>>
>
> Okay, will do that. I guess it could set/append the python path to include
> the resource folder in the py script that calls pybot to run the tests. This
> would of course, be a workaround to not being able to define directory-level
> resources, instead of having to repeat it in every test like in the OP.
> Another way without touching the path could be to define the ${ABS_PATH}
> path to be used using the `get_variables()` function.

Your start-up script could also pass variable like ${RESOURCE
DIRECTORY} (or something shorter like ${RESDIR}) to pybot when it
starts it. That variable would contain the absolute path to the
directory containing your common resources, and you could use it in
your test data like `Resource ${RESDIR}/resource.txt`. If you only
have one common resource, passing just ${RESOURCE} and using it like
`Resource ${RESOURCE}` would obviously work too.

[anirudh dutt]

On Monday, October 8, 2012 2:40:26 PM UTC+8, Pekka Klärck wrote:

2012/10/5 anirudh dutt <ane...@gmail.com>:

>
> Okay, will do that. I guess it could set/append the python path to include
> the resource folder in the py script that calls pybot to run the tests. This
> would of course, be a workaround to not being able to define directory-level
> resources, instead of having to repeat it in every test like in the OP.
> Another way without touching the path could be to define the ${ABS_PATH}
> path to be used using the `get_variables()` function.

Your start-up script could also pass variable like ${RESOURCE
DIRECTORY} (or something shorter like ${RESDIR}) to pybot when it
starts it. That variable would contain the absolute path to the
directory containing your common resources, and you could use it in
your test data like `Resource  ${RESDIR}/resource.txt`. If you only
have one common resource, passing just ${RESOURCE} and using it like
`Resource  ${RESOURCE}` would obviously work too.

Yes, this is exactly what I ended up doing. Easy enough to pass variables to pybot this way.

COREFLOWSDIR = os.path.join(TESTDIR, 'Core-Flows/resources')
ROBOT_ARGS.append("--variable")
ROBOT_ARGS.append("core_flows_dir:%s" % COREFLOWSDIR)

(along with one more which changes but is an absolute path so is always used the same way in all test files). Like:

***Settings***
Resource	${CORE_FLOWS_DIR}/Master_Test_Flow.txt

Thanks
- Anirudh