This was not as easy as the other two. The main issue involves the `BaseDriver` class and is threefold:
1. `BaseDriver` and a valid external subclass thereof (a `Driver`) are not the same, because the former is essentially _abstract_. There is no notion of an abstract class in JS nor in TS for JS.
2. Splitting `BaseDriver` into several modules and "mixing in" some modules is just not well-understood by TS.
3. `AppiumDriver` inherits _most_ of `BaseDriver`, but overrides some functions with differing signatures. This is unsupported by TS.
To work around these problems, I had to:
1. Move the `Driver` interface into `@appium/types`, since other packages may depend on it. We do not want circular dependencies, which is likely to occur otherwise. Further, there is no way to tell TS for JS that a class _implements_ an interface or type.
2. Refactor the mixins (in `basedriver/commands/`) into "mixin classes", as understood by typescript. These are dynamic classes returned by functions which accept a class parameter, and _extend_ that class. The result is marginally better, but the implementation is ... well, see for yourself. It is not possible to use declaration merging to just "trick" TS into thinking that `BaseDriver` has all of these extra methods; classes cannot be merged, and even if you could, you can't use declaration merging to "add" methods afaict.
3. `BaseDriver` is now an empty class which inherits from all mixins applied to `DriverCore`. Due to syntactic restrictions, it must be a `class` statement in order to use the `@implements` tag, which causes TS to check that the result fully implements `Driver`. `AppiumDriver` _also_ inherits from `DriverCore`, since it does not override `BaseDriver` "properly". `BaseDriverCore` itself is pretty small, containing only those functions which `AppiumDriver` defines as differing.
Otherwise:
- `BaseDriver` does not inherit from `Protocol`, which is just an empty class. `Protocol` was removed.
- All of the error classes are exported from `protocol/errors`, because TS cannot see them otherwise.
- Exported missing `GET_STATUS_COMMAND` from `protocol/index`
- Re-exported `normalizeBasePath` from `server` instead of `protocol`, since that's where it's defined
- Removed `index.d.ts`
- Mixins use `@implements` as well. Note that `@implements` does not support `import('..')` syntax.
chore(base-driver): attempted to make types for mixins less awful
fixed a couple issues in the types in `driver.js`
core(base-driver): add capabilities types
- also move the bluebird config into the index
- fix references to `DriverOpts`
- add `assignServer()` to `BaseDriverCore`, used by `AppiumDriver`
chore(base-driver): fix more types
add missing reference to `@appium/types` in `tsconfig.json`
fix(base-driver): ensure getLogEvents is async
fix(base-driver): add some more type checks and fix logCustomEvent to be async
chore(base-driver): reformat
This PR removes Gulp from `@appium/base-driver` and reorganizes the test files.
The build needs to be a little different since other modules depend on its `build/test/basedriver` module. IMO this should probably get moved elsewhere, but this does not break compatibility.
simplified some stuff that was giving me problems.
instead of doing a try..await..catch and calling `fail()` if the catch block wasn't called, just use `sinon-chai`'s `.should.eventually.be.rejectedWith(ErrorClass, /message/)`
depending on the order in which this test file is run versus others, it's possible that some will fail because of global logging weirdness. but normally this doesn't happen... keep an eye on it!
* chore: ban direct usage of sinon
Calling `sinon.stub()`, `sinon.mock()` etc., directly is error-prone. Care must be taken to explicitly restore any stub created.
Using a sandbox (via `sinon.createSandbox()`), you don't need to remember to restore everything you fiddled with.
To that end, I've converted all direct `sinon` calls into sandbox calls and **BANNED** direct usage of `sinon` via ESLint.
# Conflicts:
# .eslintrc
* test(base-driver): replace restricted sinon.spy() usage in server-specs.js
* test(support): formatting
- `base-driver` gets a new `helpers` module with a `getTestPort` function; this is now used throughout the tests
- `fake-driver` can't use random ports because it depends on `appium-base-driver`'s test suite, and that is _not_ the current appium-2.0-compatible `@appium/base-driver`
This PR makes `chai` and `should()` _globals_ when using Mocha:
- `chai` is configured with `chai-as-promised`
- A `.mocharc.js` requires `./test/setup.js` _from the monorepo root_.
- Updated the ESLint config to recognize the globals.
- Updated Wallaby config
All instances of `import chai...` and the like have been removed from all test files.
Just a bunch of random (mostly path-related) fixes.
## Monorepo
- Make `npm run clean` work cross-platform
- Sort root `package.json`
- Update Babel configs to suppress warning about `@babel/plugin-proposal-private-property-in-object`
- Add `.nyc_output` and `*.lerna_backup` to `.gitignore`
- Replace references to `appium-support`
- Sync `package.json` fields
- Add a [Wallaby](https://wallabyjs.com) configuration file
## appium
- `lib/config`: `package.json` resolution
- split some tests out of `config-specs.js` and into `config-e2e-specs.js` since they are very clearly not unit tests
- Improve `PROJECT_ROOT` resolution, which is still a hack
- Copy fixtures & fix paths to fixtures in tests
## @appium/base-driver
- `lib/basedriver/driver`: `package.json` resolution
- Fix broken tests when run in isolation (`chai.should()`)
## @appium/doctor
- `lib/doctor`: `package.json` resolution
- `lib/utils`: `package.json` resolution & exposed `resetLog()` which undoes what `configureBinaryLog()` does (for testing purposes)
- `utils-specs.js`: clean up after `onLogMessage` test
- copy fixtures into `build` upon transpile
- Upgrade `@appium/gulp-plugins`
## @appium/gulp-plugins
- Ensure `postTranspile` is run when `transpile` is run before tests
- Fix `.babelrc` like `babel.config.json`
## @appium/support
- Fixture resolution
- Fix broken tests when run in isolation (`chai-as-promised`)
- Copy fixtures when transpiling
* chore: update @appium/fake-driver to use @appium/base-driver
BREAKING CHANGE: `fake-driver` now depends upon `@appium/base-driver@8.x`
## `@appium/fake-driver`
- need to use w3c capabilities only
- fix: find `app.xml` fixture properly when running tests via `mocha --require=@babel/register`
## `@appium/base-driver`
- fixed a dead URL in a comment
- updated the "logging" tests to manually supply w3c capabilities. `createSession()` does it for you, but `executeCommand('createSession')` does not.
- display the name of the driver under test when executing base driver's test suite with other drivers
Ref: #15425
* fix(fake-driver): add naive css selector support
* fix(fake-driver): helpers now use wdio instead of wd
- exported more constants as base-driver helpers do
- `deleteSession()` now expects a wdio `browser` (`driver`) object; removed closure
* fix(fake-driver): find-element-tests and driver-e2e-specs members passing
- alert-tests, context-tests, element-interaction-tests, general-tests all failing still
* fix(fake-driver): update interaction tests
replace unsupported `getLocation` with `getElementRect`
* fix(fake-driver): update alert tests
* fix(fake-driver): udpate context tests
* fix(fake-driver): update unit tests
* fix(base-driver): implement missing route for releaseActions
is the call to `this.proxyReleaseActions` even necessary?
* fix(fake-driver): update generic actions tests
also add a stub implementation of `releaseActions`, which wdio calls
* chore(fake-driver): remove redundant tests from find-element-tests
covered by other strategies
* fix(fake-driver): update generic actions tests
also fix path to screenshot (`screen.png`) when running tests outside of `build`
* chore(fake-driver): use fs module from @appium/support
* chore(base-driver): update hash in protocol consistency test
* fix(base-driver): update e2e test fn to prefer provided address/port over default
* chore: formatting
Mykola Mokhnach