appium / appium-base-driver Goto Github PK

This is an option available in the iOS simulators:
http://i.stack.imgur.com/ml3L9.png

This will allow more comprehensive testing of negative path flows for TouchID UI integration.

Something like:

POST /wd/hub/session/{sessionId}/appium/simulator/touch_id_enrolled/
BODY: {isEnrolled: true|false}
Set or unset simulator to TouchID enrolled state

• Make sure all deps are up to date (and there are no unused deps)
• Take a look at all TODOs to see if we need to resolve any for the release
• Set up code coverage
• Set up CI (unit tests, functional tests, code coverage; should be on all relevant platforms, and should include multi-executor parallelism for long-running testsuites)
• Ensure that we are using appium-support functions, not home-grown helpers
• Ensure that we have high unit test code coverage percentage
• Ensure that we have sufficient/appropriate functional test coverage
• Write a decent README, explaining (a) what the purpose of the module is, (b) how it relates to other appium modules, and (c) how to use its interface
• Ensure that code conforms to our style
• Ensure we are not using any sync functions
• Ensure that code is well-commented
• Ensure that non-production code or assets are added to .npmignore to reduce npm install size

We need to unset the sessionID if creating a session fails, so that a new session can be created.

Drivers should surround their 'createSession' in a try/catch and undo their state. They should also call super.destroySession or undoSession or whatever we want to call it. This method should unset the sessionId.

cc @imurchie

Problem

When I do stuff with Appium (in this case Android), I can see the following types of logs:

info: --> POST /wd/hub/session/2993a4c6-a7c5-4403-8a21-d399e567c7f4/element/0.843447342980653-1/click {}
info: JSONWP Proxy: Proxying [POST /wd/hub/session/2993a4c6-a7c5-4403-8a21-d399e567c7f4/element/0.843447342980653-1/click] to [POST http://127.0.0.1:9515/wd/hub/session/3892423514d63a5ef6424b78a7664f10/element/0.843447342980653-1/click] with body: {}

Note that there are two different session IDs:
2993a4c6-a7c5-4403-8a21-d399e567c7f4 (actual session Id)
3892423514d63a5ef6424b78a7664f10 (session ID of the android driver)
I am not entirely sure if I have associated the session Ids right. However the problem is that when I call GET /wd/hub/sessions I get

{ sessionId: '',
  status: 0,
  value:
   [ { capabilities: [Object],
       sessionId: '3892423514d63a5ef6424b78a7664f10' } ] }

It seems that the response contains the session ID from the android driver (3892423514d63a5ef6424b78a7664f10) which is not useful if you want to close the session.

Suggestion

I would replace the session Id of the android driver with the actual session Id and add another field (maybe driverId) to propagate the driver session Id too.

Right now the timeout is set when a command finishes, and cleared when a command comes in. I think it would be better to understand it as 'no command running' timeout, integrate it better with the queue, and cancel it when we pick the next command instead of when the command comes in.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Missed that, we don't want to propagate test dependencies in non test code, the dependency are not installed when you do npm install in a parent.

If we need to share test we should probably move the tests to their own package.

cc @jlipps

Protractor uses url data:text/html,<html></html> to defer Angular bootstrap, but this URL isn't valid according to the setUrl method.

Each test fails with error Url or Uri must start with <scheme>://

https://github.com/appium/appium-base-driver/blob/master/lib/mjsonwp/routes.js#L178

should match:

https://www.w3.org/TR/webdriver/#dfn-accept-alert

Alongside dismiss alert, send alert text, and get alert text.

According to the source code it is the file extension which determines wether or not the file should be unzipped.

The problem: I cannot use URLs without extensions.
The trick: Using fake URL parameters, such as https://my.url/without/extension?fake=.zip.
The solution(s): Using a module which does not rely on the file extension (e.g. file-type or allow the file format to be passed as a desired capability?

I've noticed in the [Node docs for WriteStream] specify an 'open' event to indicate when a writable stream is opened for writing. I believe that the downloadFile function should Promisify the call to createWriteStream and then await on that Promise before continuing.

Helpers should be exported.

See comments in there: #17

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

The idea of command is to create a new object for each request and pass it the information it needs to execute (bit like PageObject). It's harder to write, but more maintabable.

Then commands use helpers like findElOrEls which are on the prototype. This way we can separate the protocol from internals. Right now if you look at the commands and helpers, they are the same, which is a little weird.