JUnit tests failing with a TestTimedOutException

Question & Answer Builds
1

Bitrise Build Issue Report template

Description of the issue

Some unit tests that mock network connections fail every time with a TestTimedOutException. The tests work fine on our local development machines, on our in-house jenkins build and in our current hosted CI environment.

Just to be clear, the issue is not with the tests timing out, as we changed the timeout multiple times to about 30s now. It seems there’s a problem with the environment since the tests work fine on our local machines as well as our existing CI solutions (both local and cloud hosted).

Environment:

Where did the issue happen?

Android & Docker on Ubuntu 16.04. The 14.04 LTS doesn’t get past the install-missing-android-tools step.

Which build Step causes the issue and which version of the step?

We tried both Gradle Unit Test (1.0.4) and Gradle Runner (1.6.3 and 1.8.0).

Reproducibility

  • Does a “Rebuild” help? (You can trigger a rebuild from the Build’s page, by clicking the “Rebuild” button in the top right corner of a finished build) : NO
  • Does a rebuild without caches help? (You can remove the Cache:Pull and Cache:Push steps temporarily to not to use the cache, or you can delete all the caches on the Settings tab of the app. : NO
  • Does the issue happen sporadically, or every time? : every time
  • Does upgrading the build Step to the latest version help? : NO
  • When did the issue start? : since we imported the project

Local reproduction

It works both from the IDE and the terminal, executing the gradlew command (no exception is thrown). The issue can be reproduced with Bitrise CLI on a dev machine.

Local reproduction: Linux / Android (docker based) stack builds

Yes, it can be reproduced on the latest Bitrise android docker image.

Build log

https://www.bitrise.io/api/build/ad1a2a7ae5287e36/logs.json?&download=log

2

Hi @eduardobarrenechea,

Thanks for filling out the issue report template! :slight_smile:

How do you mock those tests? By mocking I guess you mean it does not perform an actual network call, right? In that case I’d say the way you mock those network calls is what’s causing the issue.

Checking the logs I’d say why it does not fail on your in-house Jenkins / development machine is because you have older Android tools there. Can you try to open the Android SDK manager on your dev machine and update your Android Tools?

From the log:

w: /REDACTED/UploadServiceTest.kt: (133, 34): The corresponding parameter in the supertype 'REDACTED' is named 'id'. This may cause problems when calling this function with named arguments.

This warning is for the tests which fails. Can it be the reason?

In any case, can you try to print more debug logs in these tests, to pinpoint what exactly fails?

1 Like
3

Hi Viktor,

We’re faking a network connection with interceptors at the application layer, so no network calls are made. The warning you mentioned doesn’t really affect the tests since this specific method is not tested with in this particular test suite and the warning is just for a method parameter name we changed from the supertype (will only cause issues when using named parameters in a method call in kotlin).

I’ve tried changing the build tools, as you suggested without any success. The tests continue to work from dev machines while failing on the Bitrise environment. I’ve added some logging to our unit tests but, as far as I can tell, the thread that should be invoking the interceptor is not called for those tests.

In any case, even if the problem is with how we’re mocking the network calls, we still need to understand why it works fine on every other environment we use and not with Bitrise.

https://www.bitrise.io/api/build/01c6825ede426685/logs.json?&download=log

5

You can find the whole environment provisioning code of the Linux/Docker stack (docker images) at:

If you can send us a sample project where we can reproduce the issue we can also try to dig into this. But in general, as you can see in the Dockerfiles, we do absolutely nothing special. We just install the Android tools, exactly the way it’s described in the official guides. No magic :slight_smile:

6

Also, did you try to upgrade the Android packages on your dev machine?