Spoon fails to capture a screenshot due to a difference between the actual class hierarchy, and the expected class hierarchy

[ncweinhold]

We are using Spoon as part of our automated tests for an Android application.

We have code similar to:

public class TestSample extends OurOwnInstrumentationClass {

    @Override
    public void setUp() {
        // does some set up common to our tests
        // captures a screenshot here
    }

    public void testSomethingOrOther() {
        // does a test here
    }

    public void testSomethingElse() {
        // does another test
    }
}

where OurOwnInstrumentationClass extends the ActivityInstrumentationTestCase2 of Android.

When running the test, Spoon fails to capture a screenshot, throwing an IllegalArgumentException stating that it cannot find the test class.

From debugging the tests, it seems to be a case that findTestClassTraceElement in Spoon.java expects to find android.test.InstrumentationTestCase on the stack, however due to where we are capturing the screenshot, we have junit.framework.TestCase on the stack instead, thus the exception is thrown.

Is there a way to adjust the code so that findTestClassTraceElement is not dependent on the hardcoded "android.test.InstrumentationTestCase" string?

[JakeWharton]

We use a custom instrumentation test class as well and haven't seen problems. I think your problem is more the fact that we currently don't support taking screenshots in the setUp method. This is because we have no way of actually knowing which test the runner is actually executing.

I'm working on getting the computer to take screenshots which should allow for this case. It's not far enough along that I'm able to test whether or not it actually will work.

[savvasdalkitsis]

Can't the method junit.framework.TestCase.getName() be used to determine the test case currently run?

It is available during setUp()

[edenman]

Currently the screenshot method doesn't take in the TestCase object so it wouldn't have any way of calling that method. We could switch to passing in the TestCase but we also need access to the current Activity and I'd hate to make the method signature uglier by requiring both.

[JakeWharton]

I think advancing #4 is the best approach to this since it will render this issue moot. The runner knows what test you are in since they execute synchronously.

[edenman]

In 1.1.4 we added the ability to specify the test/class name. Closing this out.