Add Location Strategy Keyword

[just-be-dev]

This was discussed both in #333 and #364 and here's a preliminary thought that I had.

Instead of tying the Add Location Strategy to javascript as I originally intended I've designed it so that a location strategy is actually implemented as a keyword. This gives a lot of flexibility in that location strategies can (if desired) be written directly in RF as a user keyword.

Keep in mind that this is just a rough draft to get started with.

Idealistically I'd have this

*** Settings ***
Library    Selenium2Library
Resource    Locators
Resource    Web Navigation Stuff

*** Keyword ***
Setup Locators
    Add Location Strategy    custom    My Custom Locator

*** Test Cases ***
My Test
    [Setup]    Setup Locators
    Open Browser To My Site
    Click Element    custom=mySelector[example=true]

[just-be-dev]

@emanlove, could you take a look at this and give me your thoughts?

Thanks.

[just-be-dev]

This is now feature complete and ready for review. I've added tests and documentation.

It includes two new keywords:

• Add Locator Strategy
• Remove Locator Strategy

The locator strategy itself is a user keyword as shown in the documentation. This allows easy integration with JavaScript (which was my original goal), but also covers any other applicable situation.

An added locator strategy will stay present throughout the duration of testing unless removed by Remove Locator Strategy.

[just-be-dev]

Add Locator Strategy is a global action. When this keyword is called, the locator strategy that is specified doesn't go away unless Remove Locator Strategy is subsequently called.

Global alterations of a testing environment by a test are generally unwise. @pekkaklarck, @emanlove what do you think of this behavior? I suppose it would be possible through library listener methods to automatically unregister the locator strategy after the scope it was registered in has subsided.

Which would be better? The current behavior (after it's set anywhere it stays until it is removed) or the scoped behavior (where if it's set in a test it's removed after that test is complete).

[pekkaklarck]

@zephraph, automatically removing locator strategies sounds like a good idea. Library listeners ought to make implementing it pretty simple. Should probably be configurable with an argument like auto_remove=False, though.

[just-be-dev]

I've added a specific test because I was in talks with @IlfirinPL on #376. This test case will likely be removed before merge along with the changes mentioned by @pekkaklarck above.

Don't merge this as is.

[just-be-dev]

@pekkaklarck, when you get a chance could you review this?

Adding the auto unregister made it a bit more complicated.

[just-be-dev]

@emanlove, could you please review this? Actually, look over everything in the 1.7 Milestone. I really want to go ahead and push a new release this weekend.

[just-be-dev]

A large part of the bulk of this is the scoping as suggested by @pekkaklarck. The original implementation made it persistent by default. This implementation makes it scoped by default (which required hooking into listeners). I try to make a little event system so if we needed to do stuff like this in the future we could just add new events.

[pekkaklarck]

Sorry, I was on a business trip with limited time for other work. What commits/code should be reviewed?

[just-be-dev]

Just look here and see if anything jumps out at you. I really would like you to look over the event system I wrote for scoping the locator registration and tell me if it's too much.

[pekkaklarck]

Parens? Also in unregister below. #pep8

[just-be-dev]

Ah, good catch. That's my Javascript habits kicking in.

[pekkaklarck]

The event system looks pretty neat but I'm not entirely sure is it necessary for this usage. Are you planning to use it for something else too? If not, then there's a risk that YAGNI.

I also added some nitpicking comments about style. I'm not sure is there any agreed styles for this project so feel free to ignore them.

[just-be-dev]

Well, it's quite possible I could use it again in the future, but I can't guarantee that. That's just how I thought to implement it. Also, I trimmed the scope events down a bit. It's more DRY now.

[pekkaklarck]

Ok, looks good.

[just-be-dev]

So, are we good to merge?

[divfor]

I have an idea on similar enhancement:
https://github.com/divfor/robotframework-selenium2library/pull/6
This enhancement is to simplify locator usage. Generally it is difficult for junior engineers and customer to understand the locators written in user keywords or test steps. It would be better if they can use Web UI texts/words prompting for target element instead of locators. The real locators could be mapped by prompting UI text in variable files created and maintained by senior engineers. If so, the test cases will be more easier to read.

[just-be-dev]

I'm not really following you. The custom locators written here should be specified in a resource file or library, not included in a test. I wrote this feature with javascript frameworks like angular and ExtJs in mind, though it's not limited to those sorts of things. I would say it's more up to the locator developer to document their locator usage. By and large this should be a rarely used feature though.