moredip / Frank

Automated acceptance tests for native iOS apps
www.testingwithfrank.com
Apache License 2.0
1.21k stars 237 forks source link

Shelley extensions #209

Open ondrejhanslik opened 11 years ago

ondrejhanslik commented 11 years ago

I have worked with Frank for a while and I noticed there are many things I can't do and they would be nice to have so I would like to open a discussion about possible Shelley extensions (I am willing to implement any of them).

Accessibility elements

Shelley can currently inspect only views. However, some of the user interaction can be done only through accessibility elements. One example is the iOS native keyboard which uses elements with type UIAccessibilityTraitKeyboardKey and UIAccessibilityTraitButton.

It would be nice to have accessibility selectors, e.g. uiaelement:button marked:'Hide Keyboard'. This could be easily combined with the view hierarchy, e.g. view:'MyCustomView' uiaelement:button

This would also require to add some additional interaction selectors (e.g. FEX_touch) on NSObject. There is already a similar code for Mac.

Custom predicates

Currently there are predefined predicates, e.g. marked:, markedExactly:, isAnimating etc. The all have to return a BOOL. There is no possibility to use logical operations (NOT, OR). It would be nice to allow custom predicates without the need to add custom UIView methods.

Proposal example: view filter:"tag = 10"

This could be easily implemented using NSPredicate and -[NSArray filteredArrayUsingPredicate:], automatically enabling comparisons and logical operations.

This could be actually implemented in Frank using -[UIView filter:] method but implementation directly in Shelley makes more sense.

Inspecting views returning from methods

Some of the views are very difficult to describe only using marked. It would be nice to have the possibility to find a view and then get next views using selectors on the first view. Cons: The grammar could get complicated

E.g. view:'UITableView' {"tableHeaderView"} or view:'UITableView' {"headerViewForSection:", 0}

Sorting

The index predicate usually doesn't work properly because the view ordering is random. Unfortunately, it is needed for some situations, e.g. testing if table view cells are sorted correctly.

It would be nice to have a possibilty to sort the returned selectors:

Proposal: view:'UITableViewCell' sort:position

moredip commented 11 years ago

Thanks for starting to explore this - I've wanted to support UIAccessbilityElement in queries for a while. Lots of other interesting ideas here too.

Could you start a thread about this in the Frank mailing list? This is something which is meaty enough to have some good community discussion I hope. Also there are some folks on the list who have implemented alternate view selector engines with some of the features you describe (e.g. NSPredicate support). It's be great to get their perspectives.

Cheers,

Pete

Typed on a little bitty keyboard

On May 13, 2013, at 2:39 AM, ondrejhanslik notifications@github.com wrote:

I have worked with Frank for a while and I noticed there are many things I can't do and they would be nice to have so I would like to open a discussion about possible Shelley extensions (I am willing to implement any of them).

Accessibility elements

Shelley can currently inspect only views. However, some of the user interaction can be done only through accessibility elements. One example is the iOS native keyboard which uses elements with type UIAccessibilityTraitKeyboardKey and UIAccessibilityTraitButton.

It would be nice to have accessibility selectors, e.g. uiaelement:button marked:'Hide Keyboard'. This could be easily combined with the view hierarchy, e.g. view:'MyCustomView' uiaelement:button

This would also require to add some additional interaction selectors (e.g. FEX_touch) on NSObject. There is already a similar code for Mac.

Custom predicates

Currently there are predefined predicates, e.g. marked:, markedExactly:, isAnimating etc. The all have to return a BOOL. There is no possibility to use logical operations (NOT, OR). It would be nice to allow custom predicates without the need to add custom UIView methods.

Proposal example: view filter:"tag = 10"

This could be easily implemented using NSPredicate and -[NSArray filteredArrayUsingPredicate:], automatically enabling comparisons and logical operations.

This could be actually implemented in Frank using -[UIView filter:] method but implementation directly in Shelley makes more sense.

Inspecting views returning from methods

Some of the views are very difficult to describe only using marked. It would be nice to have the possibility to find a view and then get next views using selectors on the first view. Cons: The grammar could get complicated

E.g. view:'UITableView' {"tableHeaderView"} or view:'UITableView' {"headerViewForSection:", 0}

Sorting

The index predicate usually doesn't work properly because the view ordering is random. Unfortunately, it is needed for some situations, e.g. testing if table view cells are sorted correctly.

It would be nice to have an ability to sort the returned selectors:

Proposal: view:'UITableViewCell' sort:position

— Reply to this email directly or view it on GitHub.