miguel-perez/smoothState.js

Improve "onReady waited duration ms" test sensitivity to timing in testAPI.js

Open

#208 opened on Aug 14, 2015

View on GitHub
 (0 comments) (0 reactions) (0 assignees)CSS (4,433 stars) (515 forks)batch import
enhancementhelp wanted

Description

When I submitted PR #203, the Travis CI rejected my build when this test failed on line 84 of testAPI.js. After testing and retesting on my own PC I could not reproduce the failure, and there was really no good reason for my changes to cause it to fail. I noticed that on my PC, running all tests takes about 1.5 seconds, but the CI reports 25ish seconds to complete the tests, so I became suspicious that the test is inherently susceptible to timing failures, if only by very small margins.

I subsequently resubmitted my PR as #207 and the CI machine accepted by build. All tests passed. This seems to support my claim that, at the very least, this test is flaky under different test environments and specifically because of timing issues.

I feel like reducing the duration expected for the onAfter function call to be delayed may take care of this, but I'm not familiar with the reasoning for it being set to 50ms in the first place.

Contributor guide

Tech stack
javascript
Domain
testing
Issue type
test
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
familiarity with JavaScript testing
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
65
Research direction
Investigate line 84 in testAPI.js, which contains a timing sensitive assertion. The test likely uses setTimeout; consider using a mock timer or adjusting the expected delay. Review PRs #203 and #207 for context on the flaky behavior. Also check if the test framework provides utilities for handling async operations deterministically.