On Software Development

Calabash Android Command Line Options and Environment Variables

noreply@blogger.com (Niels Sthen Hansen) — Fri, 13 Feb 2015 08:31:00 +0000

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.

Commands

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

help

prints very brief help information.

build

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

build <apk>

run

run <apk>

Uses cucumber options, see below.

gen

Generate a features folder structure.

console

open calabash console

console <apk>

setup

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

resign

Re-signs the app with the currently configured keystore.

version

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]*] ]+

Examples:
cucumber examples/i18n/en/features
cucumber @rerun.txt (See --format rerun)
cucumber examples/i18n/it/features/somma.feature:6:98:113
cucumber -s -i http://rubyurl.com/eeCl

-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.

Lessor app is out

noreply@blogger.com (Niels Sthen Hansen) — Wed, 12 Oct 2011 08:01:00 +0000

The Lessor app just made it to the Android market. Check it out!

Published with Blogger-droid v1.7.4

Android Tutorial GOTO Århus

noreply@blogger.com (Niels Sthen Hansen) — Fri, 07 Oct 2011 14:26:00 +0000

Link to files at the Android Tutorial, GOTO Århus 2011:

https://docs.google.com/#folders/0B_C0TFg2y2ezYTYyMTlmM2MtYzY0ZC00OGIwLWFlNTctYTFmMTJiYWQ5OTlk

Or if you do not have a google account:

http://dl.dropbox.com/u/20657490/androidtutorial.zip

And the slides:

http://dl.dropbox.com/u/20657490/GOTO_android_tutorial_presentation.pdf

A solution for Hands-On 1-5 (minus extras):

http://dl.dropbox.com/u/20657490/androidtutorialsolution.zip

Wicket Webinar

noreply@blogger.com (Niels Sthen Hansen) — Fri, 28 May 2010 12:40:00 +0000

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.

Don't Think - Just Write Tests, Right ?

noreply@blogger.com (Niels Sthen Hansen) — Sat, 16 May 2009 09:14:00 +0000

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

You have no bugs anywhere...
OR .. you have a bug in your application code but the test that was supposed to cover it is faulty as well!
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.

SFTP in Java with JSch Using Private Key Authentication

noreply@blogger.com (Niels Sthen Hansen) — Fri, 14 Mar 2008 13:56:00 +0000

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

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

        final Vector files = sftp.ls(".");
        for (Object obj : files) {
            // Do stuff with files
        }
        sftp.disconnect();
        session.disconnect();
    }

    ...

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

Lean and Metaphors

noreply@blogger.com (Niels Sthen Hansen) — Fri, 15 Jun 2007 13:16:00 +0000

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.

.NET Class Generation - Delegating Object Properties

noreply@blogger.com (Niels Sthen Hansen) — Thu, 31 May 2007 08:18:00 +0000

In a recent assignment I had the need for a dynamically generated class that - among other things - could be generated with a field of arbitrary type and delegate the properties of said field. In other words something like


public class MyWrapperClass : MyParentClass
{
private ObjectType _WrappedObject;

public ObjectType WrappedObject
{
    set { _WrappedObject = value; }
}

public string Field1
{
    get { return _WrappedObject.Field1; }
}

public int Field2
{
    get { return _WrappedObject.Field2; }
}

// ... other stuff
}

where ObjectType can be any type and MyParentClass is a base class.

Fortunately, .NET reflection and class generation is pretty straight-forward. Generating the class itself requires an assembly, module etc.:


AppDomain appDomain = Thread.GetDomain();
AssemblyName assemblyName = new AssemblyName();
assemblyName.Name = "MyAssembly";
AssemblyBuilder assemblyBuilder
= appDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule("MyModule");
TypeBuilder typeBuilder
= moduleBuilder.DefineType("MyWrapperClass", TypeAttributes.Public);
typeBuilder.SetParent(typeof(MyParentClass));

The field holding our wrapped object must be declared to be the same type as the object to be wrapped


private ObjectType _ObjectToBeWrapped

This can be done with the following code:


Type objectType = wrappedObject.GetType();
FieldBuilder wrappedObjectField
= typeBuilder.DefineField("_WrappedObject", objectType, FieldAttributes.Private);

We will also need a setter for the object


public ObjectType WrappedObject { set { _WrappedObject = value; } }

And this requires some IL code generation:


// Create property ObjectToBeWrapped
PropertyBuilder wrappedObjPropertyBuilder
  = typeBuilder.DefineProperty("WrappedObject", PropertyAttributes.None,
  objectType, null);

// Create property setter
MethodBuilder wrappedObjSetBuilder =
  typeBuilder.DefineMethod("set_WrappedObject", MethodAttributes.Public,
  null, new Type[] { objectType });
ILGenerator wrappedObjSetILG = wrappedObjSetBuilder.GetILGenerator();
wrappedObjSetILG.Emit(OpCodes.Ldarg_0);
wrappedObjSetILG.Emit(OpCodes.Ldarg_1);
wrappedObjSetILG.Emit(OpCodes.Stfld, wrappedObjectField);
wrappedObjSetILG.Emit(OpCodes.Ret);
wrappedObjPropertyBuilder.SetSetMethod(wrappedObjSetBuilder);

Note that the "set { value = .. }" notation actually corresponds to a method "set_MyProperty(object value) {...", much like Java-style getters & setters.

Now for the fun bit: Create a getter for each property in the wrapped object. We iterate through the properties and generating a getter method works much like the setter above.


foreach (PropertyInfo propertyInfo in objectType.GetProperties())
{
  string name = propertyInfo.Name;
  if (IgnoreProperty(name))
  {
     continue;
  }
  PropertyBuilder propertyBuilder =
     typeBuilder.DefineProperty(name, PropertyAttributes.None,
     propertyInfo.PropertyType, null);

  MethodBuilder getBuilder =
     typeBuilder.DefineMethod("get_" + name, MethodAttributes.Public,
     propertyInfo.PropertyType, Type.EmptyTypes);

  ILGenerator getILG = getBuilder.GetILGenerator();
  getILG.Emit(OpCodes.Ldarg_0);
  getILG.Emit(OpCodes.Ldfld, wrappedObjectField);
  getILG.Emit(OpCodes.Call, propertyInfo.GetGetMethod());
  getILG.Emit(OpCodes.Ret);

  propertyBuilder.SetGetMethod(getBuilder);
}

JavaFX in IntelliJ IDEA

noreply@blogger.com (Niels Sthen Hansen) — Fri, 25 May 2007 12:08:00 +0000

No, at this point in time there is no JavaFX plugin for IDEA. It is fairly simple to get it up and running, though.

1. First you want to get openjfx (subversion or .zip).

2. Create a Java project in IDEA and put the files from trunk/lib (Filters.jar, javafxrt.jar & swing-layout.jar) in the classpath (e.g. add as a project library).

3. Create a .fx file

4. Create a run configuration

Basically you want to run net.java.javafx.FXShell with your .fx file as an argument.

4. Make sure that your .fx file is in the classpath
..Otherwise it won't work

As for syntax highlighting this can be set up by making a file type definition for *.fx files:

So all in all pretty ugly. A real JavaFX plugin is still on the IDEA wishlist.

And yes, there is already a plugin for Eclipse. There is also a fairly comprehensive tutorial using NetBeans on openjfx.dev.java.net