284e3445aa
This patch updates the tests in this file as follows: * startTime of a newly created (play-pending) animation is unresolved -> Covered by 'startTime of a play-pending animation is unresolved' in wpt/web-animations/interfaces/Animation/startTime.html However, it would be useful to have a test a new CSS animation is play-pending so I have extended the test in test_animation-playstate.html to cover this. * startTime of a newly created (pause-pending) animation is unresolved -> Covered by 'startTime of a pause-pending animation is unresolved' in wpt/web-animations/interfaces/Animation/startTime.html * startTime is resolved when running -> Covered by 'startTime is resolved when running' in wpt/web-animations/interfaces/Animation/startTime.html * startTime is unresolved when paused -> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html * startTime while pause-pending and play-pending -> Moved to wpt/web-animations/timing-model/animations/pausing-an-animation.html * startTime while play-pending from finished state, startTime while play-pending from finished state using finish() -> Merged and moved to wpt/web-animations/timing-model/animations/playing-an-animation.html * Pausing should make the startTime become null -> Simplified and merged into the test for 'startTime is unresolved when paused' / 'Pausing clears the start time' test in wpt/web-animations/timing-model/animations/pausing-an-animation.html * Sanity test to check round-tripping assigning to a new animation's startTime -> Updated and left. * Skipping forward through animation -> This is really testing two things: (a) That you can seek a CSS animation using the start time. For this it makes sense to have a separate test that also checks that the computed style is updated (like we have for current time). (b) That seeking a CSS animation using the start time triggers dispatching events. This patch splits the above into two separate tests. * Skipping backwards through animation, Redundant change, before -> active, then back, Redundant change, before -> after, then back, Redundant change, active -> before, then back, Redundant change, active -> after, then back, Redundant change, after -> before, then back, Redundant change, after -> active, then back -> All these tests are really just exercising event dispatch which is already covered by test_event-dispatch.html. Provided we have a test that checks that events are dispatched when setting the startTime we don't need to test each combination again since we have tests for each of these combinations already when using the currentTime to seek and we can assume UAs are following the same code path at this point. As a result this patch drops these tests. * Setting startTime to null -> Covered by 'Setting an unresolved start time sets the hold time' in wpt/web-animations/timing-model/animations/setting-the-start-time-of-an-animation.html * Animation.startTime after pausing -> Covered by the new 'Pausing clears the start time' test in wpt/web-animations/timing-model/animations/pausing-an-animation.html * Animation.startTime after canceling -> Merged into wpt/web-animations/timing-model/animations/canceling-an-animation.html and made it follow the spec a little more closely (which requires clearing the start time and hold time). --HG-- extra : rebase_source : 9bb3d82e18e5c2d9654576502a1d4263a1e46daa |
||
---|---|---|
.. | ||
animation-model | ||
interfaces | ||
resources | ||
timing-model | ||
OWNERS | ||
README.md | ||
testcommon.js |
Web Animations Test Suite
Specification: https://drafts.csswg.org/web-animations/
Guidelines for writing tests
-
Try to follow the spec outline where possible.
For example, if you want to test setting the start time, you might be tempted to put all the tests in:
/web-animations/interfaces/Animation/startTime.html
However, in the spec most of the logic is in the “Set the animation start time“ procedure in the “Timing model” section.
Instead, try something like:
/web-animations/timing-model/animations/set-the-animation-start-time.html
Tests all the branches and inputs to the procedure as defined in the spec (using theAnimation.startTime
API)./web-animations/interfaces/Animation/startTime.html
Tests API-layer specific issues like mapping unresolved values to null, etc.
On that note, two levels of subdirectories is enough even if the spec has deeper nesting.
Note that most of the existing tests in the suite don't do this well yet. That's the direction we're heading, however.
-
Test the spec.
-
If the spec defines a timing calculation that is directly reflected in the iteration progress (i.e.
anim.effect.getComputedTiming().progress
), test that instead of callinggetComputedStyle(elem).marginLeft
. -
Likewise, don't add needless tests for
anim.playbackState
. The playback state is a calculated value based on other values. It's rarely necessary to test directly unless you need, for example, to check that a pending task is scheduled (which isn't observable elsewhere other than waiting for the corresponding promise to complete).
-
-
Try to keep tests as simple and focused as possible.
e.g.
test(t => { const animation = createDiv(t).animate(null); assert_class_string(animation, 'Animation', 'Returned object is an Animation'); }, 'Element.animate() creates an Animation object');
test(t => { assert_throws({ name: 'TypeError' }, () => { createDiv(t).animate(null, -1); }); }, 'Setting a negative duration throws a TypeError');
promise_test(t => { const animation = createDiv(t).animate(null, 100 * MS_PER_SEC); return animation.ready.then(() => { assert_greater_than(animation.startTime, 0, 'startTime when running'); }); }, 'startTime is resolved when running');
If you're generating complex test loops and factoring out utility functions that affect the logic of the test (other than, say, simple assertion utility functions), you're probably doing it wrong.
It should be possible to understand exactly what the test is doing at a glance without having to scroll up and down the test file and refer to other files.
See Justin Searls' presentation, “How to stop hating your tests” for some tips on making your tests simpler.
-
Assume tests will run on under-performing hardware where the time between animation frames might run into 10s of seconds. As a result, animations that are expected to still be running during the test should be at least 100s in length.
-
Avoid using
GLOBAL_CONSTS
that make the test harder to read. It's fine to repeat the the same parameter values like100 * MS_PER_SEC
over and over again since it makes it easy to read and debug a test in isolation. Remember, even if we do need to make all tests take, say 200s each, text editors are very good at search and replace. -
Use the
assert_times_equal
assertion for comparing times returned from the API. This asserts that the time values are equal using a tolerance based on the precision recommended in the spec. This tolerance is applied to both of the values being compared. That is, it effectively allows double the epsilon that is used when comparing with an absolute value.For comparing a time value returned from the API to an absolute value, use
assert_time_equals_literal
. This tests that the actual value is equal to the expected value within the precision recommended in the spec.Both
assert_times_equal
andassert_time_equals_literal
are defined in a way that implementations can override them to meet their own precision requirements. -
There are quite a few bad tests in the repository. We're learning as we go. Don't just copy them blindly—please fix them!