Tests failing in 2.0 with TimeOutException

Build Environment Running Tests
1

Hi All,

I am facing issue during migration from 1.0 to 2.0. Tests were never used to fail in 1.0 but in 2.0 it is failing with unusual behavior.

Below is the test run step where gradlew scripts are used to run the testcases,

  • run:
    name: Launch test suite
    command: ./gradlew testPlayBinary && ./run build_success

Test cases are written in Scala. In every build exactly 2 testcases are getting failed with below exception in Circle 2.0.

Building 82% > :testPlayBinary > 37 tests completed, 8 skippedscalatest.WithMockedServerSuite > com.amadeus.asr.utils.refdata.updater.RefDataUpdaterSpec.Database reference data updater should load program if existing FAILED
java.util.concurrent.TimeoutException at RefDataUpdaterSpec.scala:52

When the testcases are run locally or with 1.0 they dont fail.
I tried to run by commenting out the test case after using a new cache for the dependencies, then a new set of test case starts failing with the same TimeoutException exception.
When I checked the Scala failing test cases, the common behavior I observe is all the test cases are using “Await.result(some function, 15 seconds)”.

Tried using no_output_timeout: 40m as well, But the problem did not resolve.

It would be great if I get some leads on this.

2

It is tempting to apply the logic that if the tests do not fail in those other cases, there is a problem with the new CI. However, it is working perfectly for thousands of people, so that is not very likely (not impossible though).

I can’t advise on Scala since I don’t use it, but I imagine you can debug this. What I suggest is to get everything in your build image (temporarily) that you need to build your app (compilers etc) and then use the SSH option with a console editor (nano) to do some live debugging. Edit, compile, and run - then repeat as required. Bear in mind this consumes your build minutes until you cancel the job.

I assume there is a filter on your test runner so you can run just the failing tests, so you don’t have to run the whole suite every time.

This approach has been very useful for me when debugging my PHP/PHPUnit tests - thankfully I don’t have an intermediate compilation step!

3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.