Add command line option support for Android

[friederbluemle]

This will enable cucumber-android test projects that are started through the activity manager (adb shell am instrument) to receive additional Cucumber options from the command line.

General
A normal test project would be started like this:

adb shell am instrument -w com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

The activity manager (am) supports additional extras for the instrument command:

adb shell am instrument -w -e key value com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

Multiple extras can be passed like this:
-e key1 value1 -e key2 value2

Supported Cucumber options

am instrument argument	Cucumber option
-e glue PATH	--glue PATH
-e format FORMAT[:PATH_OR_URL]	--format FORMAT[:PATH_OR_URL]
-e tags TAG_EXPRESSION	--tags TAG_EXPRESSION
-e name REGEXP	--name REGEXP
-e dryRun true -e noDryRun true	--[no-]-dry-run
-e monochrome true -e noMonochrome true	--[no-]-monochrome
-e strict true -e noStrict true	--[no-]-strict
-e snippets [underscore|camelcase]	--snippets [underscore|camelcase]
-e dotcucumber PATH_OR_URL	--dotcucumber PATH_OR_URL
-e features [ [FILE|DIR][:LINE[:LINE]*] ]+	[ [FILE|DIR][:LINE[:LINE]*] ]+

Single argument for Cucumber options
A single argument extra for the Cucumber options is also supported:

adb shell am instrument -w -e cucumberOptions "--dry-run --name 'My Test'" com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

When using cucumberOptions all other Cucumber option extras will be ignored.

A few things to note

• You cannot pass just a key without a value, that means a boolean option such as --strict would have to be passed like this: -e strict true
• Feature references can be passed: -e features [ [FILE|DIR][:LINE[:LINE]*] ]+
• Values containing spaces need to be passed like this: -e name "'My Feature'"
• It is not possible to pass the same key multiple times, e. g. -e name Feature1 -e name Feature2 would result in the first name argument being overwritten by the second name argument: The test app would only see Feature2.
  In order to pass options more than once, you would need to separate the values by two dashes --, like this: -e name Feature1--Feature2

This pull request also adds support for the following legacy test runner arguments

am instrument argument	Description
-e count true	Count the number of tests (scenarios)
-e debug true	Wait for a debugger to attach before starting to execute the tests. Note: This was added by PR #613 already.
-e log true	Enable Cucumber dry-run (same as --e dryRun true)
-e coverage true	Enable EMMA code coverage
-e coverageFile "/path/coverage.ec"	Set the file name and path of the EMMA coverage report

Asking for comments from the community, especially on the selection of the option value separator. I don't particularly like the two dashes, but it works. Does anyone have a better suggestion?

The requirements are simple: It has to be a character or separator that is

1. command line compatible (that means & and | will not work)
2. not already used by Cucumber (e. g. , as in --tags @tag1,@tag2
3. unlikely to appear in any feature name, file/path/url name, or tag name

Thanks

[friederbluemle]

Can someone please restart the Travis CI build? It failed because of some unrelated Maven error.

[aslakhellesoy]

@friederbluemle done!

[aslakhellesoy]

One thing that bothers me a little with this is that it might be hard to keep in sync with RuntimeOptions.

What if you could do this instead:

adb shell am instrument -w -e cucumber.options "--format pretty --strict" com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

I think that would simplify the implementation considerably.

Also, since release 1.1.5 you can also define cucumber options in the CUCUMBER_OPTIONS environment variable:

CUCUMBER_OPTIONS="--format pretty --strict" adb shell am instrument -w com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

Wouldn't that just work without your change?

[SierraGolf]

@friederbluemle I just saw this PR and I am really happy to have this feature soon. fyi: I am currently working on a PR for the android-maven-plugin to also support adding instrumentation args so that one could easily pipe the args all the way through from the pom/cli to the CucumberInstrumentation.

[aslakhellesoy]

@SierraGolf / @friederbluemle what do you think about my suggestion to just use CUCUMBER_OPTIONS?

Or if that doesn't work (it should) - just use -e cucumber.options "..."

[SierraGolf]

I think the environment variable will not work because the environment of the adb call is another than the one in which the actual instrumentation runs.

to use just one cucumber.options variable is something I would also prefer, because of the following two reasons:

1. it provides more flexibility to extend the options without touching unrelated code like the cucumber-android project, open-closed-principle.
2. it gives the parameters a more distinct name space, which could avoid conflicts when executing through the android-maven-plugin or other abstractions on top of the adb commands.

[aslakhellesoy]

I think the environment variable will not work because the environment of the adb call is another than the one in which the actual instrumentation runs.

Could you try just to be sure? I would think the environment variables passed to adb would be inherited by any sub processes.

[friederbluemle]

@aslakhellesoy
I also thought about using only one parameter for all Cucumber options, but I decided against it for the following reasons:
CucumberInstrumentation should behave and feel like a first class Android test runner. An Android test runner has full control over the arguments it receives from the activity manager (am). Therefore it makes sense to have full support for single parameters, just like InstrumentationTestRunner supports multiple arguments. InstrumentationTestRunner is the default and standard test runner for Android test projects. Both InstrumentationTestRunner and CucumberInstrumentation extend android.app.Instrumentation. So it feels right to make them operate in a very similar way. It would also make it easier to modify existing Ant build files for automation tests, since the format of the parameters closely resembles how they are used in InstrumentationTestRunner.

Using the CUCUMBER_OPTIONS environment variable as suggested did not work for me. Not sure why, but possibly for the reason @SierraGolf brought up.

As mentioned, passing a parameter that contains spaces requires the rather odd syntax "'String with spaces'". So instead of just running:

adb shell am instrument -w -e format pretty

it would require much more typing with weird quotes:

adb shell am instrument -w -e cucumber.options "'--format pretty'"

I am working on another pull request that implements some of the functionality found in InstrumentationTestRunner such as support for EMMA code coverage. It would also make use of some code from this PR.

Since RuntimeOptions is not expected to change frequently, I think the minimal effort it takes to keep support in cucumber-android in sync is acceptable. Of course, it would be ideal if there was a way to automatically adjust/match the different argument format used by Cucumber and activity monitor.

@SierraGolf / @mfellner / @aslakhellesoy
Thoughts?

[SierraGolf]

Since RuntimeOptions is not expected to change frequently, I think the minimal effort it takes to keep support in cucumber-android in sync is acceptable. Of course, it would be ideal if there was a way to automatically adjust/match the different argument format used by Cucumber and activity monitor.

Wouldn't that just be?

String commandLineArgs = arguments.get("cucumber.options");
if (commandLineArgs != null) {
   System.setProperty("cucumber.options", commandLineArgs.replaceAll("'", ""));
}

@friederbluemle can you rebase please? also I would like to see some test coverage as soon as we decided which way to go. I know that there are currently no tests for the CucumberInstrumentation class, so let's start now.

[mfellner]

I agree with @friederbluemle that supporting multiple arguments is the correct way to implement it for Android.

However @aslakhellesoy's concerns regarding the increased maintenance cost are also sound!

I think that in the future there should be a single class containing all possible arguments and their properties (long name, short name, values...) so that RuntimeOptions, RuntimeOptionsFactory and CucumberInstrumentation can just iterate over a list of all arguments and use them as they need to.

[aslakhellesoy]

@friederbluemle I'm not following why you need to

adb shell am instrument -w -e cucumber.options "'--format pretty'"

Why can't you just

adb shell am instrument -w -e cucumber.options "--format pretty"

[SierraGolf]

Update on the environment variable idea

$ CUCUMBER_OPTIONS="--format pretty --strict" adb shell am instrument -w com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

This has no effect since it is executed in 2 completely different processes on different machines.

$ adb shell CUCUMBER_OPTIONS="--format pretty --strict" am instrument -w com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

This does not work, because it seems to be an illegal format.

$ adb shell 
$ CUCUMBER_OPTIONS="--format pretty --strict" am instrument -w com.mypackage.app.test/cucumber.api.android.CucumberInstrumentation

Even if you would log into the adb shell first and then run the second command, it would not work because the android runtime is an isolated sandbox.

[aslakhellesoy]

@SierraGolf thanks for trying it out. Let's ditch the env var approach then.

I still want to explore if we can use -e cucumber.options "--format pretty --strict". I appreciate this might be a little unidiomatic compared to how InstrumentationTestRunner does things, but I'm not convinced this justifies the extra maintenance effort inherent in the current code.

Can we try to make cucumber.options work as a first pass, and then we can refactor core like @mfellner suggests - a class that knows about all the options - decoupled from how they are parsed/generated.

[SierraGolf]

@mfellner / @friederbluemle

An Android test runner has full control over the arguments it receives from the activity manager (am).

Why would the CucumberInstrumentation need to have any control over the cucumber command line options? It should just pass through data from the bundle. I don't see the need to have the options in separate command line args and as I already said it even brings in the problem of namespace collisions. To be save you would need to prefix everything with "cucumber", e.g. cucumber.dryRun, cucumber.strict. Furthermore having everything wrapped under cucumber.options is save, easy and consistent with the current way of working with cucumber options in java. Even if we would at some point need to access the cucumber options inside the CucumberInstrumentation it should always happen through the same abstraction which is the RuntimeOptions class.

Both InstrumentationTestRunner and CucumberInstrumentation extend android.app.Instrumentation. So it feels right to make them operate in a very similar way.

I don' t really get this argument. Why would they need to operate the same way? They do completely different things. The responsibilities of the CucumberInstrumentation should be:

• wire-up everything
• start the tests
• report results the android way

Everything else is already provided by the cucumber framework.

It would also make it easier to modify existing Ant build files for automation tests, since the format of the parameters closely resembles how they are used in InstrumentationTestRunner.

I am unsure what you mean by that, can you give an example?

Different approach
To be honest with the extension of the android maven plugin I implemented this weekend and this little wrapper, I already have the feature for free:

public class PropertyLoadingCucumberInstrumentation extends CucumberInstrumentation {

    @Override
    public void onCreate(final Bundle bundle) {
        loadBundleIntoSystemProperties(bundle);
        super.onCreate(bundle);
    }

    private void loadBundleIntoSystemProperties(final Bundle bundle) {
        for (final String key : bundle.keySet()) {
            System.setProperty(key, bundle.getString(key));
        }
    }
}

I needed this anyway because I do not have access to the Bundle in my step and hook definitions. Maybe we can add this little wrapper to the module so that users can choose to either take the CucumberInstrumentation directly or the PropertyLoadingCucumberInstrumentation.

Btw. here are some example calls of the extended android maven plugin:

mvn clean install -Dandroid.test.instrumentationArgs="cucumber.options '--tags @wip'","otherProp otherValue"
mvn clean install -Dandroid.test.instrumentationArgs="cucumber.options features/awesome.feature"
mvn clean install -Dandroid.test.instrumentationArgs="cucumber.options '--name Some\\sScenario'"

[mfellner]

I think for now we should just implement the simpler solution, which is to pass cucumber.options as a single key-value pair. This requires less code to achieve the goal. Later on the ability to provide individual key-value pairs for every option can still be added additionally.

@friederbluemle, can you confirm that using spaces inside the value string requires double quotes? If you can just pass the list of options as a string like, e.g.,

-e cucumber.options "--strict --format pretty --glue cucumber.examples.java.helloworld"

then you can just split the string by spaces and pass it on to RuntimeOptions:

String[] args = str.split("\\s+");
RuntimeOptions runtimeOptions = new RuntimeOptions(new Env("cucumber-jvm"), args);

@SierraGolf Maven integration looks great. But can we include the functionality of PropertyLoadingCucumberInstrumentation into CucumberInstrumentation? I think the handling of any arguments should be the job of CucumberInstrumentation. I'd rather avoid using a subclass for two reasons:

• Users need to choose one of two options when writing AndroidManifest.xml.
• Principle of using composition instead of inheritance when possible.

[aslakhellesoy]

then you can just split the string by spaces and pass it on to RuntimeOptions:

No, don't split by spaces - this would screw up options like this:

--name  'The fox'

See #379 for details.

I'll make some changes to RuntimeOptions to prevent accidental incorrect usage like this. After you have done that you should be able to simply do:

String commandLineString = ...;
RuntimeOptions runtimeOptions = new RuntimeOptions(new Env("cucumber-jvm"), commandLineString);

[mfellner]

@aslakhellesoy, you are correct, I missed that. So we can use this instead:

Properties properties = new Properties();
properties.setProperty("cucumber.options", arguments.getString("cucumber.options"));
new RuntimeOptions(new Env(properties));

Or a variation thereof with iterating over arguments like in @SierraGolf's example or another variation where System.setProperty is used (in that case Env() or Env(String bundleName) need to be called somewhere I suppose).

In any case I would be in favor of first implementing a simple approach of this kind.

[aslakhellesoy]

Ok, so with 4ed29b0 in place, this is how you'd do it:

new RuntimeOptions(arguments.getString("cucumber.options"));

Simple!

[SierraGolf]

Please keep in mind that the functionality should be as follows:

• try to get options from first found class annotated with @CucumberOptions
• command line arguments override any previously found cucumber options

[SierraGolf]

@SierraGolf Maven integration looks great. But can we include the functionality of PropertyLoadingCucumberInstrumentation into CucumberInstrumentation? I think the handling of any arguments should be the job of CucumberInstrumentation. I'd rather avoid using a subclass for two reasons:

• Users need to choose one of two options when writing AndroidManifest.xml.

Yeah that is the point, because not everyone might want the bundle piped through to the system properties. I think it is in general a nice feature, but people might be surprised to see that the CucumberInstrumentation simply puts all bundle information into the system properties.

• Principle of using composition instead of inheritance when possible.

I am with you on that, one would need to implement an abstract ForwardingInstrumentation which provides forwarding of the public interface methods to a decorated Instrumentation. I did not do that for my example to keep it simple, but that should be done in case we would like to pull this in.

[friederbluemle]

Wow this has turned into a lively discussion.. Thanks everyone for your comments :)

I'm not following why you need to

adb shell am instrument -w -e cucumber.options "'--format pretty'"```

This example of course does not make sense. Sorry about that. You would only need single quotes if a value inside of Cucumber options contains spaces:

adb shell am instrument -w -e cucumber.options "--name 'My Feature'"

I still want to explore if we can use -e cucumber.options "--format pretty --strict"

Yes that is possible and is implemented in the latest code.

Why would the CucumberInstrumentation need to have any control over the cucumber command line options? It should just pass through data from the bundle. I don't see the need to have the options in separate command line args and as I already said it even brings in the problem of namespace collisions. To be save you would need to prefix everything with "cucumber", e.g. cucumber.dryRun, cucumber.strict.

I understand your concern about namespace clashes, but like I said, CucumberInstrumentation has full control over the arguments. The name CucumberInstrumentation already implies "Cucumber", so there is no need for another prefix. It is the responsibility of this class to provide a sensible interface to activity monitor and the outside world, while trying to preserve the native behavior of Android test runners.

Furthermore having everything wrapped under cucumber.options is save, easy and consistent with the current way of working with cucumber options in java.

Yeah, I get your point about how Cucumber options work in Java. But unfortunately it is not consistent at all with how test runners for Android are expected to work. CucumberInstrumentation extends android.app.Instrumentation, which is a part of the Android framework.
However I am open to the idea of supporting a single Cucumber options string as an argument (implemented in the latest code).

I don' t really get this argument. Why would they need to operate the same way? They do completely different things.

I would argue that they do very similar things: They both run test cases. The only difference is that CucumberInstrumentation executes Cucumber features and InstrumentationTestRunner is based on plain JUnit tests. Sure, behind the scenes they do completely different things, but that is not the point here. The outside interface (i. e. the way arguments get passed) should be modelled in a similar and consistent way.

Different approach
To be honest with the extension of the android maven plugin I implemented this weekend and this little wrapper, I already have the feature for free

If that was ever a consideration, I would strongly advise against blindly setting all supplied arguments as system properties. This could have unintended side effects, as other components might use system properties as well. Also, Cucumber options are not the only arguments that can be supplied to this test runner. As I mentioned in an earlier comment, I have reimplemented some of the existing functionality of InstrumentationTestRunner to work with CucumberInstrumentation and these arguments would be of no value to Cucumber or worse, might cause problems.

I'll make some changes to RuntimeOptions to prevent accidental incorrect usage like this.

Great! One question, can you confirm that these two Cucumber options strings are equivalent:

--name "The fox"

--name 'The fox'

The reason I'm asking is because only variant (1) works on the command line:

(1) -e key "--name 'The Fox'"
(2) -e key '--name "The Fox"'

Otherwise we would need to replace single quote with double quote before passing the string.

With the latest rebase, both a single Cucumber option strings and separate arguments are supported, with the single string taking precedence over separate arguments. The class annotations have the lowest priority.
In the future, as @mfellner suggested, the best way to handle this is to iterate over all supported options and parse them automatically. When this is available, it would be great to replace the manual parsing code.

@aslakhellesoy As you can see in the code, the options are still set as a system property. Could you please advise on how to make use of your new RuntimeOptions constructor and still have class annotation support.
This is how RuntimeOptions are currently created:

RuntimeOptionsFactory factory = new RuntimeOptionsFactory(optionsAnnotatedClass, new Class[]{CucumberOptions.class});
runtimeOptions = factory.create();

[aslakhellesoy]

Great! One question, can you confirm that these two Cucumber options strings are equivalent:
--name "The fox"
--name 'The fox'

Unix shells will parse both of these in the same way. The shell creates the array ["--name", "The fox"] which it passes to the command you're launching. For Java that's the String[] in your main function.

I don't know if Windows will parse them the same way.

As you have discovered, our own naive shellwords implementation only handles single quotes. I factored it out in 8f01484 and added a couple of ignored failing tests. @friederbluemle do you want to try and make them pass? As you can see from 976111f you can't just replace signle quotes to double quotes.

As for the RuntimeOptionsFactory question, I'll have to change that. I'm going to be unavailable for a couple of weeks, so it will have to wait. Of course, you can try to refactor it yourself.

[mfellner]

I think this issue has already been a little bit overcomplicated. There is now a straightforward solution to fulfill the basic requirement of supporting command line arguments:

• Use CucumberOptions annotation by default.
• If cucumber.options argument (single string) was provided, create RuntimeOptions like this instead:

new RuntimeOptions(arguments.getString("cucumber.options"));

• If neither an annotation or argument was provided, throw exception.

Then the next step would be to allow a combination of annotation and command line argument. One straightforward way would be to implement a merge interface in RuntimeOptions. Then you could create two RuntimeOptions instances and just options1.merge(options2), overwriting values in 1 with values from 2, or the other way around.

Finally, additional support for separate key-value pairs for each cucumber option can be implemented.

I think it would be better to declutter this whole issue and work little by little in small incremental changes.

[friederbluemle]

Sounds good! I'll start to work on that over the next couple of days.
By the way, have you thought about just using defaults instead of throwing an exception in the case where no Cucumber options are set explicitly? I think we would only need "features" for the feature path. All other options already have defaults.

[SierraGolf]

I am a little confused now on what the consensus is about multiple/single argument, but wanted to give a hint about this line of code anyway. I think you can inline this method by simply using arguments.getBoolean(tag) in case the default should be false, or use arguments.getBoolean(tag, true)in case the default should be true.

[SierraGolf]

Never mind, I just double checked and found out that the Bundle helper methods are not working in this context.

[friederbluemle]

Yeah, unfortunately arguments.getBoolean(tag, true) cannot be used here, since it casts the value to a Boolean instead of parsing a String.

[dimgit]

If a merge interface is implemented as suggested above (options1.merge(options2) etc), can the implementation be such that it supports multiple @CucumberOptions by merging them in a specified order, with later options overriding earlier ones?
Currently, it is a bit limiting - specifically, with Android and running from Eclipse, there is not a good way to specify alternative options, without changing the ones already defined. This is needed in cases where a developer may want to use specific options while working on a task, for example, without modifying the project @CucumberOptions.

[aslakhellesoy]

@dimgit could you please create a new issue for RuntimeOptions.merge. What you're adking sounds reasonable.

[dimgit]

Done. See #608

[friederbluemle]

Added support for legacy InstrumentationTestRunner arguments:

• count
• debug
• coverage
• coverageFile
• log

See updated PR description.
debug has already been added through PR #613. I did some minor refactoring when I rebased and removed the code duplication.

[SierraGolf]

@friederbluemle I know this thread goes on for a while already and that we both want this to get merged because this would unblock us from continuing development etc. but I still think there is a miss-understanding. I think @aslakhellesoy, @mfellner and me want to have a single argument for the cucumber options for now.

[mfellner]

want to have a single argument for the cucumber options for now.

Yes, I think this would be good. Additional features should be added incrementally, we might even create issues for them.

[friederbluemle]

As mentioned in the comment on Oct 15th, a single argument for the Cucumber options is supported:

-e cucumberOptions "--dryRun --name Test"

Updated the PR description accordingly.

But I guess the discussion is more about removing the getCucumberOptionsString method and with it the already working support for multiple arguments. I completely agree that this method is not an ideal solution and would require manual updates in order to keep it in sync with the available Cucumber options. But let's understand what we are talking about here: We're taking away the expected (and correct) behavior for the end user because of an implementation detail. I wonder how often the supported Cucumber options actually do change, if synchronization is the main concern.
At least two other classes do a similar kind of string parsing already and would require manual changes as well: RuntimeOptions and RuntimeOptionsFactory. That does not mean it's good, but that would just add InstrumentationOptions to the list of classes that would benefit from a refactoring.

May I suggest the following at this time:

• Merge now to enable further development with the other updates in place and refactor later (together with the other classes) - or -
• Make a specific proposal on how to refactor the three classes now by using a single, flexible source of truth for supported Cucumber options.

I am asking this because a significant amount of work has been put into this already, the code is working perfectly fine and is unit tested.

[erikb76]

Hi guys, my team and I are already using a custom build of cucumber-android jar in order to make use of -e tags and -e coverage arguments
It would be great to have it in an official release soon. Thanks for your hard work!

[SierraGolf]

@friederbluemle Sorry, I did not see that both single and multiple arguments are supported. So I am fine.

@mfellner / @aslakhellesoy If you guys are fine with it, I will merge this one and throw in some refactorings to add some test coverage. We should also document the arguments in the README and btw. is there any good document which describes what the options do?

[friederbluemle]

@SierraGolf

We should also document the arguments in the README

Good idea! This PR is definitely not a place to keep permanent documentation. ;) If someone can point me to a document, I can write something up.

[brasmusson]

@SierraGolf (One place where) The options are described is in the Usage.txt, which is displayed on the -h option.

@friederbluemle I recon that the Android module README.md is a place to document command line support for Android.

[SierraGolf]

@brasmusson wow, that is well hidden. I feel that for the cucumber-jvm modules there should be a more prominent place, like on the website, where options and module specific behaviour should be documented. I feel the entry into cucumber world for the JVM languages is quite difficult, especially when you are not coming from the ruby world.

[aslakhellesoy]

It's high time we unite our forces to move docs over to the website. It currently lives on https://github.com/cucumber/cucumber.github.com.

Feel free to start adding documentation there.

[brasmusson]

@SierraGolf There is a heading for the description of the options on the website (where https://github.com/cucumber/cucumber.github.com is published), but the description is currently only a TODO. I don't even know if I saw it before I pointed to the Usage.txt
I just added some structure and a minimal description how to run using JUnit to that page, so any time you feel up to it @friederbluemle, there is a heading for the Android case.

[rafaelaazevedo]

Hi guys, I know this is old, but I am running the command:

adb shell am instrument -w -e cucumberOptions "'--tags @settings'" com.rsouza.test/.Instrumentation

and it's not generating cucumber reports

[vgaidarji]

@rafaelaazevedo Have you tried adb shell am instrument -w -e cucumberOptions "--out reportsDirectory --format html --tags @settings" com.rsouza.test/.Instrumentation?

[rafaelaazevedo]

@donvigo not, it's returning:
Error: Bad component name: html

I've tried html, pretty, junit, anything just to see the report

[vgaidarji]

I'm running cucumber tests using calabash:
bundle exec calabash-android build "_PATH_TO_APK_"
bundle exec calabash-android run "_PATH_TO_APK_" --format json -o cucumber.json --tag _TAGS_ ADB_DEVICE_ARG=_CONNECTED_DEVICE_ID_HERE_

Try "-o" param instead of "--out".

[dkowis]

Please take the discussion up on the mailing list: http://cucumber.io/support This is for bugs and defects only! :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.