#565 FIX#646
#565 FIX#646TikhomirovSergey merged 9 commits intoappium:masterappium/java-client:masterfrom TikhomirovSergey:masterCopy head branch name to clipboard
Conversation
but it needs to be covered with tests
- bug fixes - test coverage
|
@SrinivasanTarget @amedvedjev could you take a look at the PR? |
|
@amedvedjev Are you talking about the WIKI page? |
|
@TikhomirovSergey yes. on wiki. |
Also documentation was improved
|
@amedvedjev @SrinivasanTarget @SrinivasanTarget could you please approve it if everything is ok? |
SrinivasanTarget
left a comment
There was a problem hiding this comment.
Few Comments in readme. Overall cool stuff. 👍
docs/Page-objects.md
Outdated
| @HowToUseLocators(iOSAutomation = ALL_POSSIBLE) | ||
| @iOSFindBy(someStrategy1) | ||
| @iOSFindAll(value = {@iOSBy(subloctor1), @iOSBy(subloctor1)}, priority = 1) //this possible variant is | ||
| // the chain |
There was a problem hiding this comment.
Can we update this section as below please?
@HowToUseLocators(iOSAutomation = ALL_POSSIBLE)
@iOSFindBy(someStrategy1)
@iOSFindBys({
@iOSBy(parentLocator),
@iOSBy(childLocator)},
priority = 1) //this possible variant is the chain
@iOSFindBy(someStrategy2, priority = 2)
@iOSFindBy(someStrategy3, priority = 3)
RemoteWebElement someElement;
ALL_POSSIBLE contains CHAIN
| @iOSFindBy(someStrategy2, priority = 2) | ||
| @iOSFindBy(someStrategy3, priority = 3) | ||
| RemoteWebElement someElement; | ||
|
|
There was a problem hiding this comment.
CHAINING Contains ALL_POSSIBLE. Awesome👍
docs/Page-objects.md
Outdated
| @HowToUseLocators(iOSAutomation = ALL_POSSIBLE) | ||
| @iOSFindBy(someStrategy1) | ||
| @iOSFindAll(value = {@iOSBy(subloctor1), @iOSBy(subloctor1)}, priority = 1) //this possible variant is | ||
| // the chain |
| if (selendroidFindByArray != null && selendroidFindByArray.length == 1) { | ||
| return createBy(new Annotation[] {selendroidFindByArray[0]}, HowToUseSelectors.USE_ONE); | ||
| } | ||
| List<Annotation> annotations = new ArrayList<>(asList(annotatedElement.getAnnotationsByType(singleLocator))); |
There was a problem hiding this comment.
nit: extra space here
There was a problem hiding this comment.
Ok. I am working on the improving.
There was a problem hiding this comment.
:) The code is very well written. Although things like this bother my internal perfectionist.
There was a problem hiding this comment.
@mykola-mokhnach I have noticed that space. Ok. Thak you.
| if (selendroidFindBys != null) { | ||
| return createBy(selendroidFindBys.value(), HowToUseSelectors.BUILD_CHAINED); | ||
| } | ||
| Annotation[] annotationsArray = annotations.toArray(new Annotation[]{}); |
There was a problem hiding this comment.
is there any particular reason to transform it back to array? lists can also be sorted without any problems
There was a problem hiding this comment.
@mykola-mokhnach Good catch. This is something like "legacy". I supposed to use array at first revisions.
| } | ||
| Annotation[] annotationsArray = annotations.toArray(new Annotation[]{}); | ||
| sort(annotationsArray, comparator); | ||
| By[] result = new By[] {}; |
There was a problem hiding this comment.
same here - why not to use list and only convert it to array on return?
There was a problem hiding this comment.
@mykola-mokhnach This is not the same. Array is returned by java by design. Comporator can work with collection and array so why we have to covert it to a list?
There was a problem hiding this comment.
result = add(result, createBy(new Annotation[] {a}, HowToUseSelectors.USE_ONE));
I suppose this will create a new copy of the array on each call and this is not the case for a list where we can add elements to the same instance.
| if (androidFindByArray != null && androidFindByArray.length == 1) { | ||
| return createBy(new Annotation[] {androidFindByArray[0]}, HowToUseSelectors.USE_ONE); | ||
| Method value; | ||
| Annotation[] set; |
There was a problem hiding this comment.
can this variable have some more descriptive name?
| } | ||
| By result = null; | ||
| if (isSelendroidAutomation()) { | ||
| result = buildMobileBy(howToUseLocators != null ? howToUseLocators.selendroidAutomation() : null, |
There was a problem hiding this comment.
I'm always a bit suspicious about using method calls with ternary operator, since Java will invoke the method even if the precondition equals to false
There was a problem hiding this comment.
same question to all the further ternary operator usages in such context (with method invocation instead of constant values)
| if (iOSFindBys != null) { | ||
| return createBy(iOSFindBys.value(), HowToUseSelectors.BUILD_CHAINED); | ||
| } | ||
| if (isAndroid() && result == null) { |
There was a problem hiding this comment.
exchanging operands
result == null && iisAndroid()
could make it faster
There was a problem hiding this comment.
in general one can simplify it by adding
if (result != null) {
return result;
}
before all these conditions. Then it won't be necessary to check whether it is equal to null in all the further conditions
There was a problem hiding this comment.
@mykola-mokhnach There are some difficulties.
It is by design. When selendroind-mode-specific annotations are not defined there when it is possible to use '@AndroidFindBy-s' at some cases. The same is true for iOSXCUITFindBy-s/iOSFindBy-s
There was a problem hiding this comment.
...however I know how to make to look it better.
There was a problem hiding this comment.
Do you want to say that isAndroid() method (and others) may implicitly change the value of result?
| int p1 = getPriorityValue(priority1, o1, c1); | ||
| int p2 = getPriorityValue(priority2, o2, c2); | ||
|
|
||
| if (p2 > p1) { |
There was a problem hiding this comment.
the whole condition can be replaced with
return Integer.signum(p1 - p2);
|
@mykola-mokhnach @SrinivasanTarget |
Change list
#565 FIX. The new feature implementation.
Types of changes
Details
There annotations were re-designed (some annotations were added)
All these annotations are repeateble. The use case is described here.