Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add partial xpath support to ignore identifiers in the axpath #110

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nkjith
Copy link

@nkjith nkjith commented Nov 23, 2020

In the desktop application we have, the AXIdentifier part keeps changing and this results in test case failures.
Adding partial xpath support which will ignore the identifiers and will search for the element recursively

{
return rootUIElement;
}
calls++;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what the calls variable for?

[matchedChildren addObject:foundElement];
}

return matchedChildren;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

matchedChildren.copy

NSMutableArray *matchedChildren = [NSMutableArray array];
PFUIElement* foundElement = [self findElementRecursively:rootUIElement calls:0];

if ([foundElement isNotEqualTo:nil])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cannot we simply use == for comparison here?

@@ -1190,6 +1201,107 @@ - (NSArray *)findAllUsingAXPathComponents:(NSArray *)axPathComponents rootUIElem
return @[];
}

-(PFUIElement*) findElementRecursively:(PFUIElement *)rootUIElement calls:(int)calls
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it always make sense to mention nullability in method signatures

return matchedChildren;
}

-(void) setRoleAndPredicatesOfElement:(NSString*) elementToFind
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class seems overloaded with different stuff. Would it be possible to extract lookup-specific stuff into a separate class/category? Even better, add some basic unit tests to it?


NSArray* predicateArray = parseElement[kNodePredicate][kPredicateOperations];

for (int i=0; i < [predicateArray count]; i++)
Copy link
Contributor

@mykola-mokhnach mykola-mokhnach Nov 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cannot we simple iterate over array items (for-in)?

{
id object = [predicateArray objectAtIndex:i];
NSString* attributeName = object[kPredicateAttributeName];
NSString* attributeValue = object[kPredicateAttributeValue];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

attributeValue only should be extracted inside of if block


for (int i=0; i < [predicateArray count]; i++)
{
id object = [predicateArray objectAtIndex:i];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible to have better name for this variable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants