Friday, February 13, 2015

Calabash Android Command Line Options and Environment Variables

Calabash is a really cool tool but I find the documentation for android is a bit scattered. Some general stuff is readily available online but no links to docs about environment variables or command line options. In the following I have tried to put together a bit more info about command line options and environment variables based on version 0.5.4 of the source code.


Usage: calabash-android <command-name> [parameters] [options]

prints very brief help information.


builds the test server that will be used when testing the app.

build <apk>
run <apk>

Uses cucumber options, see below.


Generate a features folder structure.


open calabash console

console <apk>

Sets up a non-default keystore .calabash_settings to use with this test project.


Re-signs the app with the currently configured keystore.


Prints the gem version

General options

    -v, --verbose

Turns on verbose logging

Environment variables

The environment variables used by calabash-android are documented in a mark-down file in the source which can be found here.

Cucumber Options

The run command forwards command line options to cucumber. The options are described by options.rb in cucumber which is invoked by

cucumber --help

For cucumber 1.3.17:
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
    -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 features.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.
    -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.
    -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.
    -a, --autoformat DIR             Reformats (pretty prints) feature files and write them to DIRECTORY.
                                     Be careful if you choose to overwrite the originals.
                                     Implies --dry-run --format pretty.
    -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.
    -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.
        --[no-]drb                   Run features against a DRb server. (i.e. with the spork gem)
        --port PORT                  Specify DRb port.  Ignored without --drb
        --dotcucumber DIR            Write metadata to DIR
        --version                    Show version.
    -h, --help                       You're looking at it.

Wednesday, October 12, 2011

Lessor app is out

The Lessor app just made it to the Android market. Check it out!
Published with Blogger-droid v1.7.4

Friday, May 28, 2010

Wicket Webinar

Did a webinar on Apache Wicket recently for Dansk IT - slides are here...

It is an odd way of presenting. You are basically just looking at your screen while talking - not much in the way of interaction with the audience. On the other hand, it is a fairly easy way to reach people you would normally not get out to because of geography so it will probably not be the last time I try this.

Saturday, May 16, 2009

Don't Think - Just Write Tests, Right ?

I gave a brief talk on Continuous Integration at the local Java User Group a few weeks ago and I happened to mention that although I value automated regression testing very much I do not think it gives you any real guarantees that your software is error free.

I think this provoked some in audience a bit - I got questions along the line of "why do you hate unit testing so much?" and I realized that I unwittingly had stepped on some toes there. Sorry guys, I hope we are still friends.

Yes, I am a sceptic but for the record: I don't hate unit testing and I certainly do not think that people who do unit testing are idiots.

What I do have a problem with are when people set up their test suite, complete with red light for errors, green light for no errors - and then conclude the following:
  • Red light: there is a bug in the application code
  • Green light: there are no bugs in the application code

I think this assumption is incredibly naive and will try to explain why.

Your test system consists of two components: The application code and the test code itself (junit test cases, mocking etc.). Software bugs can be present in either component. This should be a known fact to anyone who have been working seriously with automated testing.

Consequently, red light means you have either
  • A bug in your application code
  • OR you have a bug in your test code!

I admit that this is very useful information and it also gives you an idea about where the problem lies - it is either in the code being tested or in the test itself.

Green light on the other hand is much more tricky. Really, all it tells you is that

  1. You have no bugs anywhere...
  2. OR .. you have a bug in your application code but the test that was supposed to cover it is faulty as well!
  3. OR .. you have a bug in your application code that is not covered by a test
When we see the green light we want to believe that we are dealing with case #1 - no bugs. But we really have no way of knowing this for sure.

Case #2 is fairly common in large test systems and is generally detected by someone else down the line - either QA or the end user. How do know that your test code is error free anyway? Are you writing unit tests to test your unit tests? And if so, are you also testing the test code that is testing the original test code... ?

This brings us to case #3 which has to do with test coverage. Yes, you can minimize the case 3 bugs by writing more tests. There is a catch, however: All the new test code you write could potentially have bugs, thus introducing more of the case #2 scenarios.

If you have ten lines of test code for every line of application code it means that there is a ten times higher risk of bugs in your test code. There is some powerful mathematics working against us in our attempt to achieve a full, error-free test coverage.

Integration testing is a way to test more lines of application code with less lines of test code but the same principle applies: As your test suite grows, so does the likelihood of having bugs in the test suite.

All this doesn't mean that you should stop doing automated testing. What is does mean is that you should look at your test results with a certain amount of scepticism. A failed test means you have a problem - either with your application code or your tests. No failed tests just means that there are potential undetected problems out there. And the way to solve these problems may not be to just blindly write more test code. Don't fire your QA people just yet.

Friday, March 14, 2008

SFTP in Java with JSch Using Private Key Authentication

JSch is an excellent library for ssh in Java. One bad thing is that there is no real documentation - or rather, the source itself is the documentation. And the good news is of course that the source code is available along with a nice collection of examples.

I recently had to use SFTP from a Java application and it did take some source-diving to figure out exactly how it works (specifically to get the parameters for JSch.addIdentity right). It turned out to be rather straight-forward:


private void execute() throws JSchException, SftpException {
JSch jSch = new JSch();
final byte[] prvkey = readMyPrivateKeyFromFile(); // Private key must be byte array
final byte[] emptyPassPhrase = new byte[0]; // Empty passphrase for now, get real passphrase from MyUserInfo

"myusername", // String userName
prvkey, // byte[] privateKey
null, // byte[] publicKey
emptyPassPhrase // byte[] passPhrase
Session session = jSch.getSession("myusername", "", 22);
UserInfo ui = new MyUserInfo(); // MyUserInfo implements UserInfo
Channel channel = session.openChannel("sftp");
ChannelSftp sftp = (ChannelSftp) channel;

final Vector files =".");
for (Object obj : files) {
// Do stuff with files


The MyUserInfo class must implement the UserInfo interface. There are a number of good examples of this in the jsch distribution.

Friday, June 15, 2007

Lean and Metaphors

A criticism of Lean Software Development is hard to find. While I think it offers a number of useful ideas and tools, I am somewhat sceptic towards the widespread use of metaphors from manufacturing found in Lean Software Development: An Agile Toolkit.. and elsewhere.

Metaphors are powerful in the way that they allow us to transfer insights from one area of experience to another. However, for these insights to be valid it is required that the metaphor has the same characteristics and dynamics as the system it is supposed to model. Or to put it more bluntly: Lean will solve all your problems to the extent that your software development organisation is like a manufacturing plant...

It is not all bad, though. The assembly line model may fail to capture all aspects of software development - but it does bring issues such as queues and waste into focus and provide a framework for discussing and adressing them. So even if Lean is not the final answer to everything it remains a useful tool for certain applications.

However, if software development is a field in its own right why do we then always have to use metaphors and analogues to describe it? It is clear that there is much to be learned from viewing software development as .. well, software development.