All posts by Herb Williams

How To Connect A Test Device Over WiFi With Android Studio

The following article provides step-by-step instructions on how to connect a test device over WiFi with Android Studio. Testing Android apps will at some point require that real devices are used to ensure that features behave as expected. In Android Studio, tests run on smartphones, tablets or other hardware are known as instrumented tests. For the application under test to be installed and executed on the test device, it needs to be connected to the development PC. The default connection method is via a USB cable which has a few disadvantages. It is however possible to utilise the device’s WiFi connectivity to hook up to the development machine. Using Wifi has a number of benefits

  • WiFi won’t suddenly become unplugged during a test
  • No USB cable to get lost, broken or tangled
  • You can spin 360 degrees in your chair while holding the test device

So then, let’s connect a test device with WiFi.

  1. Get the IP address and serial number of the device from it’s settings menu
    • Settings > About Device > Status >
      • IP address
      • Serial number
  2. Connect the device to the PC via USB
  3. Get the name of the device from the list of connected devices by using adb command at the command line interface
    • “adb devices”
  4. On the development PC enter “adb -s <device name> tcpip 5555” to set the port for the device.
  5. In a terminal window, enter “adb connect <IP Address>:5555”
  6. Now you can unplug the USB cable from the device and test with freedom!


If when attempting to establish a connection to the device, you encounter the message “No connection could be made because the target machine actively refused it. (10061)”, it’s possible that there may be an issue with the port. To overcome this repeat step 4 above with a different port number i.e. 5656 then try the adb connect command with the new port number.

cucumber logo

Cucumber Usage Command Line Parameters

This article lays out the parameters and options that can be added to the cucumber command when run from the command line.

Cucumber is a software tool that helps to bring the disciplines of testing, coding and business analysis together through a Behavior Driven Development approach to software development. It executes tests based on feature files that describe user scenarios, based on a natural sounding business language.

Usage: cucumber [options] [ [FILE|DIR|URL][:LINE[:LINE]*] ]+
cucumber examples/i18n/en/features
cucumber @rerun.txt (See –format rerun)
cucumber examples/i18n/it/features/somma.feature:6:98:113
cucumber -s -i
-r, –require LIBRARY|DIR Require files before executing the features. If this
option is not specified, all *.rb files that are
siblings or below the features will be loaded auto-
matically. Automatic loading is disabled when this
option is specified, and all loading becomes explicit.
Files under directories named “support” are always
loaded first.
This option can be specified multiple times.
–i18n LANG List keywords for in a particular language
Run with “–i18n help” to see all languages
–fail-fast Exit immediately following the first failing scenario
-f, –format FORMAT How to format features (Default: pretty). Available formats:
debug : For developing formatters – prints the calls made to the listeners.
html : Generates a nice looking HTML report.
json : Prints the feature as JSON
json_pretty : Prints the feature as prettified JSON
junit : Generates a report similar to Ant+JUnit.
pretty : Prints the feature as is – in colours.
progress : Prints one character per scenario.
rerun : Prints failing files with line numbers.
stepdefs : Prints All step definitions with their locations. Same as
the usage formatter, except that steps are not printed.
usage : Prints where step definitions are used.
The slowest step definitions (with duration) are
listed first. If –dry-run is used the duration
is not shown, and step definitions are sorted by
filename instead.
Use –format rerun –out rerun.txt to write out failing
features. You can rerun them with cucumber @rerun.txt.
FORMAT can also be the fully qualified class name of
your own custom formatter. If the class isn’t loaded,
Cucumber will attempt to require a file with a relative
file name that is the underscore name of the class name.
Example: –format Foo::BarZap -> Cucumber will look for
foo/bar_zap.rb. You can place the file with this relative
path underneath your features/support directory or anywhere
on Ruby’s LOAD_PATH, for example in a Ruby gem.
–init Initializes folder structure and generates conventional files for
a Cucumber project.
-o, –out [FILE|DIR] Write output to a file/directory instead of STDOUT. This option
applies to the previously specified –format, or the
default format if no format is specified. Check the specific
formatter’s docs to see whether to pass a file or a dir.
-t, –tags TAG_EXPRESSION Only execute the features or scenarios with tags matching TAG_EXPRESSION.
Scenarios inherit tags declared on the Feature level. The simplest
TAG_EXPRESSION is simply a tag. Example: –tags @dev. When a tag in a tag
expression starts with a ~, this represents boolean NOT. Example: –tags ~@dev.
A tag expression can have several tags separated by a comma, which represents
logical OR. Example: –tags @dev,@wip. The –tags option can be specified
several times, and this represents logical AND. Example: –tags @foo,~@bar –tags @zap.
This represents the boolean expression (@foo || !@bar) && @zap.
Beware that if you want to use several negative tags to exclude several tags
you have to use logical AND: –tags ~@fixme –tags ~@buggy.
Positive tags can be given a threshold to limit the number of occurrences.
Example: –tags @qa:3 will fail if there are more than 3 occurrences of the @qa tag.
This can be practical if you are practicing Kanban or CONWIP.
-n, –name NAME Only execute the feature elements which match part of the given name.
If this option is given more than once, it will match against all the
given names.
-e, –exclude PATTERN Don’t run feature files or require ruby files matching PATTERN
-p, –profile PROFILE Pull commandline arguments from cucumber.yml which can be defined as
strings or arrays. When a ‘default’ profile is defined and no profile
is specified it is always used. (Unless disabled, see -P below.)
When feature files are defined in a profile and on the command line
then only the ones from the command line are used.
-P, –no-profile Disables all profile loading to avoid using the ‘default’ profile.
–retry ATTEMPTS Specify the number of times to retry failing tests (default: 0)
-c, –[no-]color Whether or not to use ANSI color in the output. Cucumber decides
based on your platform and the output destination if not specified.
-d, –dry-run Invokes formatters without executing the steps.
This also omits the loading of your support/env.rb file if it exists.
-m, –no-multiline Don’t print multiline strings and tables under steps.
-s, –no-source Don’t print the file and line of the step definition with the steps.
-i, –no-snippets Don’t print snippets for pending steps.
-I, –snippet-type TYPE Use different snippet type (Default: regexp). Available types:
classic: Snippets without parentheses. Note that these cause a warning from modern versions of Ruby. e.g. Given /^missing step$/
percent: Snippets with percent regexp e.g. Given %r{^missing step$}
regexp : Snippets with parentheses e.g. Given(/^missing step$/)
-q, –quiet Alias for –no-snippets –no-source.
–no-duration Don’t print the duration at the end of the summary
-b, –backtrace Show full backtrace for all errors.
-S, –strict Fail if there are any undefined or pending steps.
-w, –wip Fail if there are any passing scenarios.
-v, –verbose Show the files and features loaded.
-g, –guess Guess best match for Ambiguous steps.
-l, –lines LINES Run given line numbers. Equivalent to FILE:LINE syntax
-x, –expand Expand Scenario Outline Tables in output.
–order TYPE[:SEED] Run examples in the specified order. Available types:
[defined] Run scenarios in the order they were defined (default).
[random] Shuffle scenarios before running.
Specify SEED to reproduce the shuffling from a previous run.
e.g. –order random:5738
–version Show version.
-h, –help You’re looking at it.