Erratic test failure in master

The last master build failed with the below error. If I had to guss, this test is using an external server. We should probably bring whatever data its using in-house to make sure CI doesn’t randomly fail.

CC @likangning93 @OmarShehata

  Core/GoogleEarthEnterpriseTerrainData
    upsample
      ✗ works for all four children of a simple quad
	Error: Timeout - Async callback was not invoked within 5000ms (set by jasmine.DEFAULT_TIMEOUT_INTERVAL) in node_modules/jasmine-core/lib/jasmine-core/jasmine.js (line 5096)
	<Jasmine>
5.002 secs: Core/GoogleEarthEnterpriseTerrainData upsample works for all four children of a simple quad
3.236 secs: Core/GoogleEarthEnterpriseTerrainData createMesh creates specified vertices plus skirt vertices
1.667 secs: Core/GoogleEarthEnterpriseMetadata resolves readyPromise
1.187 secs: Core/VideoSynchronizer Syncs time when not looping
1.151 secs: Core/ApproximateTerrainHeights initializes
1.132 secs: Scene/GroundPrimitive does not pick when allowPicking is false
1.109 secs: Scene/GroundPrimitive larger scene renders batched instances
1.087 secs: Scene/Vector3DTileContent renders polygons
1.069 secs: DataSources/GeometryVisualizer Creates and removes static color open geometry
1.053 secs: Scene/GroundPrimitive picking in 2D
Firefox 63.0.0 (Linux 0.0.0): Executed 10347 of 10355 (1 FAILED) (skipped 8) (2 mins 22.893 secs / 2 mins 13.272 secs)
TOTAL: 1 FAILED, 10346 SUCCESS

[OmarShehata]

@mramato I haven’t seen any other test failures yet since. I’ll refactor the camera test this week and that’ll hopefully curb these failures. The only thing that will remain is tests using external resources (described here https://github.com/AnalyticalGraphicsInc/cesium/issues/7244) but those don’t seem to be a critical issue on Travis currently.

[ggetz]

CI seems to have passed though.

Do you see the same when running with --webgl-stub locally?

I’m not opposed to the robustness of this is striving for, but I’m leaning towards re-writing the entire suite with smaller, more focused tests.

This sounds like the best approach to me. Specs should only test one thing, and re-writing the specs seems to be the consensus in thread anyway.