Test always fails in local env

[EmmanuelMess]

Running :app:testPlayDebugUnitTest always fails with:

com.amaze.filemanager.asynchronous.asynctasks.compress.EncryptedRarHelperTaskTest > testRoot[16] FAILED
    java.lang.Exception at AndroidTestEnvironment.java:470
        Caused by: java.lang.AssertionError at Assert.java:89

[TranceLove]

@EmmanuelMess Can you run the test standalone from within Android Studio?

Also, try get a jacoco test report. It should contain more info on what had gone wrong for me to fix this.

[EmmanuelMess]

I cannot run the test from Android Studio either. It might be a timezone issue.

java.lang.Exception: Main looper has queued unexecuted runnables. This might be the cause of the test failure. You might need a shadowOf(getMainLooper()).idle() call.
	at org.robolectric.android.internal.AndroidTestEnvironment.checkStateAfterTestFailure(AndroidTestEnvironment.java:470)
	at org.robolectric.RobolectricTestRunner$HelperTestRunner$1.evaluate(RobolectricTestRunner.java:548)
	at org.robolectric.internal.SandboxTestRunner$2.lambda$evaluate$0(SandboxTestRunner.java:252)
	at org.robolectric.internal.bytecode.Sandbox.lambda$runOnMainThread$0(Sandbox.java:89)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.AssertionError: expected:<1527590280000> but was:<1527601080000>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:633)
	at com.amaze.filemanager.asynchronous.asynctasks.compress.AbstractCompressedHelperTaskTest.testRoot(AbstractCompressedHelperTaskTest.kt:83)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.robolectric.RobolectricTestRunner$HelperTestRunner$1.evaluate(RobolectricTestRunner.java:546)
	... 6 more

[TranceLove]

@EmmanuelMess Sounds like timezone problem on timestamp assertion differences. Same thing happened on zip tests earlier, so I think should be about the same problem.

Will advise after further inspection.

[TranceLove]

Made an initial test with separate VM running Debian 11, and timezone deliberately set to GMT-3, i.e. the same timezone as in Buenos Aires😎 gradle build from the command line ran ok.

Will check with tests ran from within IDE. May involve setting TZ environment variable at test run configuration.

[TranceLove]

Ran from within Debian VM of timezone = Buenos Aires again, running EncryptedRarHelperTaskTest will fail without setting TZ to UTC in run configurations.

So perhaps this is how to solve your problem - set environment variable TZ to UTC in your run configuration in Android Studio. Github action YAML and gradlew/gradlew.bat had already had this set, so they won't be affected.

[EmmanuelMess]

I dont understand why that fact that I run it under another timezone changes the result of the test, isn't everything converted to UTC timezone?

[TranceLove]

@EmmanuelMess Zip and rar formats are still using DOS timestamps, which is timezone sensitive. Things got a little tricky when verifying their timestamps, hence setting timezone to UTC to hopefully reduce the impact of the problem.

[EmmanuelMess]

Zip and rar formats are still using DOS timestamps, which is timezone sensitive.

Can't the timezone be set in code for this test?