Fixed
Status Update
No update yet.
Comments
me...@thomaskeller.biz
The link in the above description doesn't work external to google, expanded link: https://issuetracker.google.com/issues/73450636
bl...@gmail.com
This will be fixed in the next release.
ne...@gmail.com
I've got same problem. But it was because of me=)
I'm staring test with IntentsRule with 'false' third argument
and before launching activity did some work:
@Before
public void setUp() {
super.setUp();
DataPreloaded.prepareDB(getApplication());
intentsRule.launchActivity(PortfolioListActivity.intent(getApplication()));
}
and there was an error in prepareDB method.
So check your logcat before report about bug. Maybe problem in your code ;)
I'm staring test with IntentsRule with 'false' third argument
and before launching activity did some work:
@Before
public void setUp() {
super.setUp();
DataPreloaded.prepareDB(getApplication());
intentsRule.launchActivity(PortfolioListActivity.intent(getApplication()));
}
and there was an error in prepareDB method.
So check your logcat before report about bug. Maybe problem in your code ;)
sl...@google.com
ka...@gmail.com
@nekdenis
The important implication of this bug is that the exception gets swallowed up behind the NPE. The true cause of the issue must be surfaced up and shown to the user vs the rather terse NPE shown above.
If in your example, if you changed `IntentsTestRule` -> `ActivityTestRule` (and assuming you didn't use any of the respective test helpers from it) you would have again seen an exception (because of code written in your application) but the important point here is that the root cause would have been surfaced, and you would know straight away what the issue was.
I ran into the same problem when a particular class failed at the time of Dep Injection.
Because of this bug, you were forced to (just like me) google around to find the meaning of this issue. Then not find a solution and raise a bug against this problem :)
The important implication of this bug is that the exception gets swallowed up behind the NPE. The true cause of the issue must be surfaced up and shown to the user vs the rather terse NPE shown above.
If in your example, if you changed `IntentsTestRule` -> `ActivityTestRule` (and assuming you didn't use any of the respective test helpers from it) you would have again seen an exception (because of code written in your application) but the important point here is that the root cause would have been surfaced, and you would know straight away what the issue was.
I ran into the same problem when a particular class failed at the time of Dep Injection.
Because of this bug, you were forced to (just like me) google around to find the meaning of this issue. Then not find a solution and raise a bug against this problem :)
sl...@google.com
This issue has been fixed and will ship in the next release.
Description
Devices/Android versions reproduced on: any
I use the IntentsTestRule in my JUnit test to start my activity and capture intents that it issues. If the activity fails to launch for any reason, "Intents.release()" is called. In this method, "defaultInstance.internalRelease()" is called uncondtionally, i.e. also when "defaultInstance" is still null, which leads to an NPE.
Full stack trace:
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.test.espresso.intent.Intents.internalRelease()' on a null object reference
at android.support.test.espresso.intent.Intents.release(Intents.java:140)
at android.support.test.espresso.intent.rule.IntentsTestRule.afterActivityFinished(IntentsTestRule.java:68)
at android.support.test.rule.ActivityTestRule$ActivityStatement.evaluate(ActivityTestRule.java:260)
at my.package.MockServerRule$1.evaluate(MockServerRule.java:29)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at android.support.test.internal.runner.TestExecutor.execute(TestExecutor.java:54)
at android.support.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:240)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1976)
Source code of MockServerRule:
public class MockServerRule implements TestRule {
@Override
public Statement apply(final Statement base, Description description) {
return new Statement() {
@Override
public void evaluate() throws Throwable {
startServer();
try {
base.evaluate();
} finally {
stopServer();
}
}
};
}
...
}
My test class:
@RunWith(AndroidJUnit4.class)
public class LoginActivityTest {
@Rule
public final IntentsTestRule<LoginActivitySingle> mActivityTestRule = new IntentsTestRule<>(LoginActivitySingle.class, true, false);
@Rule
public final MockServerRule mMockServerRule = new MockServerRule();
@Test
public void someTest() {
Activity activity = mActivityTestRule.getActivity();
...
}
}