Specify which resource file a variable is coming from

3
votes

Robot Framework allows you to import multiple resource files containing keywords with the same names, and to call them using their full name to differentiate between them. For example, if you have Resource1.robot that has a keyword called "Test Keyword" that does some action, and Resource2.robot that also has a keyword called "Test Keyword" that does a different action, when you import both resources into a test suite, your test cases can access those keywords with the syntax Resource1.Test Keyword or Resource2.Test Keyword depending on the functionality that you want.

Is there a way to do that with variables? I have two resource files - patient_records_resource.robot and patient_search_resource.robot. patient_records_resource defines a variable ${LAST NAME EDIT} | name=lname, and patient_search_resource defines a variable with the same name ${LAST NAME EDIT} | id=last-name. I'm running into the problem where a test case imports both of those files, and needs to access both of those edit boxes at different points, and consistently picks the wrong one. I have tried things like patient_search_resource.LAST NAME EDIT with no success, but that's approximately what I'm looking for.

I know I could just rename one of them, but I'd like to use that as a last resort solution. Everyone on my team makes sure to create unique variable names within a single resource file, but coming up with unique variable names across the whole test suite to avoid these collisions would add some overhead that we don't want.

1
robotframework

1 Answers

3
votes

There is no way to do that with variables.

All variables from resource files have the same priority. If multiple variables have the same name then only the one that was imported first is taken into use. [source]

Your only options are:

  • Splitting the suite with both imports into two sub-suites, ensuring that each sub-suite only imports one of the resources.
  • Your last resort solution: modifying your variable names to all be unique.

I agree that the latter option adds a bothersome amount of overhead, but, until RF changes the way it handles variables, it's probably your best option. Personally, I prefix all variables with a sequence of letters unique to the resource file (e.g. a resource named "Member_Central_Logging_Functions" might have all variables prefixed with MCLF).