eridem / patata Goto Github PK

View Code? Open in Web Editor NEW

2.0 2.0 4.0 298 KB

🍟 Patata - Mobile Behaviour Driven Development made it easy -

Home Page: http://patata.io

License: MIT License

JavaScript 99.78% Gherkin 0.22%

android appium bdd ios test-automation

patata's Issues

Better documentation on writing definitions?

I have tests running, but I am not exactly sure how to access the iOS driver from my definitions files... I expected a global driver variable but it does not exist, this.emu seems to be what the documentation points to using but this.emu.getScreenshot does not exist...
Built in hooks seem to indicate patata.emulator.driver.takeScreenshot() works and I need to require in patata in each test, is this the case?

Add support for web

should not be too hard... then we have one tool to rule them all!

Support a long running server with a serve command?

When developing while using Cordova, or in my case ReactNative especially, but even regular native apps... spinning up appium server takes a while compared to just rebuilding the app... this is fine when running on a CI server, but it seems to me we need a dev mode for engineers to spin up a server and quickly run the cucumber tests as they are working on the project. Thoughts?

Not passing should not always exit with code 1

If you write all your tests ahead of time, you might not want to fail your tests when not everything works, this will clog up a build server that simply needs to generate a report and a progress build of the app. We need a progressBuild cli flag to not fail on test failure

Alternate file structure

I purpose that patata support searching in the same level as features and config for a folder called definition so optional you can separate definitions into their own folder if you so choose.

Dockerize

Create a container for available environments. E.g. Android.
It should have everything installed so developers does not need to worry about installing tools (e. g. Java)

Add Predefined steps

Just as calabash has generic predefined step definitions, I think patata should too:

Screenshots

You can take a screenshot

Then take a picture

Touching (tapping)

Coordinate based touches

Then I touch on screen 100 from the left and 250 from the top

Touching arbitrary views by accessibility label:

Then I touch "accLabel"

Buttons by accessibility label

Then I touch the "login" button

or by number/index (note number starts with 1 not 0)

Then I touch button number 1

Input fields (UITextFields). Note, this looks for an UITextField with the placeholder property set to the quoted string.

Then I touch the "placeholder" input field

List items (UITableViewCells) by number. Note this can only be used to touch visible cells - it doesn't try to scroll down/up.

Then I touch list item number 1

Switches (UISwitch),

Then I toggle the switch

this step works if there is a single switch. Otherwise use,

Then I toggle the "accLabel" switch
where "accLabel" should be the accessibilityLabel for the switch.

Built-in keyboard. Touching the Done/Search button

Then I touch done
Then I touch search

Map views.

Then I touch the user location

Entering text

Entering text by accessibility label:

Then I enter "text to write" into the "accessibility label" input field
Then I fill in "accessibility label" with "text to write"

Text by table (fields are by "placeholder")

Then I fill in text fields as follows:
| field | text |
| Last Name | Krukow |
| Email | [email protected] |
| Username | krukow |
| Password | 123 |
| Confirm | 123 |

Text by input field number:

Then I enter "text" into input field number 1

Clearing fields (like entering "")

Then I clear "accessibility label"

Clearing fields by number

Then I clear input field number 1

Waiting

Waiting for text, or a view with a certain accessibilityLabel

Then I wait to see "text or label"
Then I wait for "text or label" to appear

wait for something to disappear

Then I wait until I don't see "text or label"

waiting for a button with an accessibilityLabel

Then I wait for the "login" button to appear

waiting for an iOS navigation bar with a certain title,

Then I wait to see a navigation bar titled "title"

waiting for a text field

Then I wait for the "label" input field

waiting for a number of text fields

Then I wait for 2 input fields

waiting in general

Then I wait
Then I wait and wait
Then I wait and wait and wait...
Then I wait for 2.3 seconds

Back button

In an iOS navigation bar, you can touch the "back" button using

Then I go back

Swipes

Swiping an unspecified place (usually when you have big scroll view in the center of the screen). Swipe directions can be left, right, up and down.

Then I swipe left

Swiping a scroll view by index/number (and offset), or accessibilityLabel

Then I swipe left on number 2
Then I swipe left on number 2 at x 20 and y 10
Then I swipe left on "accLabel"

Swiping table cells, by number

Then I swipe on cell number 2

Pinch (for zooms)

This step makes a small pinch to zoom in or out. Either at the first scroll view of the screen, or a the center of a view with a certain accessibility label.

Then I pinch to zoom in
Then I pinch to zoom in on "accLabel"

Scrolling

Scrolling on scroll views. Direction can be left, right, up or down.

Then I scroll down
Then I scroll down on "accLabel"

Device orientation

You can rotate the device or simulator left or right.

Then I rotate device left

Assertions

Like waiting, these are usually about seeing certain text or ui components. Usually these are identified by their accessibilityLabels, component type (like a navigation bar) or pure text like in a label or a web view.

If the thing being asserted doesn't exist in the view, the test will fail.

Asserting existence of text, or a view with a certain accessibilityLabel

Then I should see "text or label"
Then I should not see "text or label"
Then I see the text "some text"
Then I don't see the text "text or label"
Then I don't see the "someview"
Then I see the "someview"

Asserting existence of buttons:

Then I should see a "login" button
Then I should not see a "login" button

More on text, prefix, suffix, and sub string.

Then I should see text starting with "prefix"
Then I should see text containing "sub text"
Then I should see text ending with "suffix"

Seeing some text fields

Then I see 2 input fields
Then I should see a "Username" input field
Then I should not see a "Username" input field

Seeing maps and user location

Then I should see a map
Then I should see the user location

No tags defined in the CLI results in no tests run

Per #6 this is no correct behavior and does not seem to work this way on android.

##Expected result:
No tags defined in the CLI, and all tests should be run.

Why do things work like this?

As I am working on pushing this forward, I am just curious as to a few engineering choices.

Why are all items required and then passed around as the deps variable? this makes it really hard to follow the code imho vs the normal process of just require what ya need.
Why is there a patata.yaml, and a config/config.yaml... both are required or are created yes none of the values are truly needed?
I get a default, but can we make the path to features a config option?
The log.exit method makes tracking down issues really hard due to lack of stack trace... can we improve on that?
The breakdown of features to step definitions is great on one hand, but I know for me and my team we would rather have JUST global, generic definitions, and only use specific ones if needed... Can we support that mindset here too?
init command is really cool, but if there is already a package.json can't we have it just add whats needed to the existing project?

Thank yo very much for indulging me here. Once I understand these items better I will be happy to help implement what needs done and PR it

eridem / patata Goto Github PK

patata's People

Contributors

Stargazers

Watchers

Forkers