Skip to main content
Under the hood, noqa drives your app through Appium. For most tests you never need to think about this — the defaults just work. But when you need finer control over how a session starts, you can pass custom Appium capabilities, and noqa applies them when it opens the app.

​
Where to set them

You can set capabilities at two levels:
  • Per test case — Dashboard → Test Cases → open a case → Configuration → Appium Capabilities. These apply to that case only.
  • Per app — Dashboard → app Settings → Appium Capabilities. These apply to every case in the app.
Case-level capabilities override app-level ones with the same key. Each capability is a key/value pair — for example the key appium:autoLaunch with the value false. The same values apply to both local and cloud runs.
Only add capabilities when you actually need them. The defaults are right for most tests.

​
Start without launching the app

By default noqa launches your app at the start of a test. Sometimes you don’t want that — for example, when the flow starts on a website rather than in the app. Set appium:autoLaunch to false. noqa still installs the app, but leaves it closed. Then describe where to start in the instructions:
The agent begins from the home screen (or the browser) instead of your app.

​
Android: apps with more than one entry point

Some Android apps have several launch activities — a normal entry, a debug entry, a deeplink handler, and so on. To make a test start from a specific one, name it with appium:appActivity. If the activity that opens is not the one you end up on (for example, a splash screen hands off to the main screen), also set appium:appWaitActivity so Appium waits for the right screen before the test begins: You can use * as a wildcard in appWaitActivity — for example *.MainActivity — when the package prefix varies between builds.