Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Android: Prepare for Espresso support #667

Merged
merged 2 commits into from Feb 23, 2014

Conversation

Projects
None yet
3 participants
Contributor

brasmusson commented Feb 12, 2014

This PR aims at making it possible to also use the Espresso framework in step definitions.

I don't find Espresso officially published through Maven, which Cucumber-JVM uses both for CI builds and deployment. Therefore Espresso is not introduced as dependency, but the PR makes it really easy to write a custom Espresso runner locally. Using the CucumberInstrumentation works exactly as before.

A local runner like this, has been successfully tested in the Cukeulator-test example:

public class EspressoInstrumentation extends GoogleInstrumentationTestRunner {
    private CucumberInstrumentationHelper helper = new CucumberInstrumentationHelper(this);

    @Override
    public void onCreate(Bundle arguments) {
        helper.onCreate(arguments);
        super.onCreate(arguments);
    }

    @Override
    public void onStart() {
        helper.onStart();
    }
}

Fixes #662.

Notes on the what I found out about the current status of Maven and Espresso:
In Quality-Tools-for-Android the Espresso jar is checked in as a local Maven repo.
A Gradle port of Espresso is available through Maven Central

Android: Extract the main content CucumberInstrumentation
To simplify custom instrumentation classes inheriting from other
instrumentation base classes, basically all content of
CucumberInstrumentation is extracted to the new helper class
CucumberInstrumentationHelper.
Member

SierraGolf commented Feb 15, 2014

I started to work on a refactoring of the instrumentation and all auxiliary classes a few months ago (mainly to increase testability). Sadly I did not yet had time to finish this. However, I think the refactored code will make your change unnecessary.

Check out the wip here

What do you think?

Contributor

brasmusson commented Feb 15, 2014

@SierraGolf I don't think your refactorings makes this PR unnecessary. They solve different problems and can be combined (your refactorings would then end up in the class CucumberInstrumentationHelper introduced in this PR).
This PR sort of gives the cucumber-android two API's for running Cucumber features:

  • use CucumberInstrumentation as instrumentation class and you are done
  • create your own instrumentation class that inherits from the instrumentation (base) class of your choice (one different from the one CucumberInstrumentation is inheriting from), only one call to CucumberInstrumentationHelper in onCreate and one call in onStart are needed.

Right now there is a use case for the second option - using Espresso in the step definitions. If (in the future) CucumberInstrumentation is changed to inherit from GoogleInstrumentationTestRunner, the second option is not needed for using Espresso in the step definitions. Then there might not be any usage scenario at all for the second option. That could be seen as a reason to not merge this PR, even if that delays the possibility to use Espresso in the step definition.

Member

SierraGolf commented Feb 16, 2014

I see your point and I agree.

If you could just rename the class from CucumberInstrumentationHelper to something with more semantic I am happy to merge this.

What about CucumberInstrumentation instead of CucumberInstrumentationHelper and the former CucumberInstrumentation becoming CucumberInstrumentationTestRunner? I know that this would break downwards compatibility, but I think cucumber for android is not yet so widely used and the naming would actually be more consistent with the default InstrumentationTestRunner and the GoogleInstrumentationTestRunner.

Contributor

brasmusson commented Feb 16, 2014

To avoid breaking backward compatibility I changed CucumberInstrumentationHelper to CucumberInstrumentationCore. I can see that there is a case for renaming CucumberInstrumentation to CucumberInstrumentationTestRunner for the sake of consistency. That can still be done, and then maybe keeping CucumberInstrumentation as deprecated for a release or two.

If you think that your naming suggestion is better, I can change to that instead.

Member

SierraGolf commented Feb 23, 2014

Agreed.

Member

SierraGolf commented Feb 23, 2014

Can you update the history.md?

SierraGolf added a commit that referenced this pull request Feb 23, 2014

@SierraGolf SierraGolf merged commit 4fc08a7 into cucumber:master Feb 23, 2014

1 check passed

default The Travis CI build passed
Details

@brasmusson brasmusson deleted the brasmusson:android-espresso-support branch Feb 23, 2014

brasmusson added a commit that referenced this pull request Feb 23, 2014

Contributor

brasmusson commented Feb 23, 2014

The History.md is now updated.

How can i use cucumber with espresso? Have you any example project?

Contributor

brasmusson commented Nov 20, 2014

@Stabilitron No, unfortunately I do not have an example project. As the PR description says, you need to define a instrumentation class that extends GoogleInstrumentationTestRunner and calls CucumberInstrumentationHelper, and use that in the manifest for the test project. You also need to add the Espresso library to your project. Note that the onCreate/onStart methods of CucumberInstrumentationHelper has been renamed create/start in Cucumber-JVM version 1.2.0.

@brasmusson
Thank you. I did as you say, and it works (i can run test from ide and see some result), but i can't get reports.
I use that annotation

@CucumberOptions(format = {"pretty","html:/data/data/com.example.myapplication/report"},features = "features")
public class CucumberActivitySteps extends ActivityInstrumentationTestCase2<MainActivity> 

and expect to receive report with command

adb pull /data/data/com.example.myapplication cucumber-report-android

But there is no any files.

I use EspressoInstrumentation from the top of this page.
I should call some methods from runner on finish or something?

Contributor

brasmusson commented Dec 7, 2014

@Stabilitron I practically haven't generated reports from cucumber-android myself, this questing is probably best asked on the mailing list.

@SierraGolf SierraGolf referenced this pull request Dec 23, 2014

Closed

Support Espresso 2.0 #813

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment