- From: Brian Birtles <web-platform-tests-notifications@w3.org>
- Date: Tue, 09 Aug 2016 07:58:59 GMT
- To: public-web-platform-tests-notifications@w3.org
> This test runs the cross product of animation states and method calls and records the resulting animation state. It makes sense from an implementation stand point to cover this as a way of tracking changes in behaviour, perhaps it makes less sense from a spec testing perspective. Yeah, the idea is that we should be testing spec conformance here. If there are tests specific to your implementation, then they probably don't belong here. > Does it sound reasonable to simply split these tests up according to the animation method being called? That way they are scoped to a section of the spec. They should probably be split up according to the procedure they are testing. The methods / attributes are mostly just hooks to procedures defined earlier in the spec so the bulk of the tests should probably be covering those procedures (i.e. under `timing-model` / `animation-model`) rather than in `interfaces`. Some things like keyframe handling, however, are specific to the API and belong under `interfaces`. (And a bunch of the existing tests are probably in the wrong place but we're gradually moving them as we touch them.) > Also you mentioned "no need to test the playState" after calling cancel(), I'm not sure I understand the motivation to not have test coverage for the effect of cancel() in that instance. The effect of `cancel()` is to call the "cancel an animation" procedure which updates the start time and hold time (observable most directly through `currentTime` being null). It's really tempting to also test `playState`, and `effect.timing.getComputedTiming().progress`, and `effect.timing.getComputedTiming().currentIteration`, and ``effect.timing.getComputedTiming().localTime`, and `getComputedStyle`, and so on--after all more testing is better, right? But in the long run, making the tests as simple and focussed as possible makes them easier to maintain, read, and write. It also makes it easy to check if the spec is being tested correctly and completely, and makes it easier to keep the tests consistent. If you have a moment, I think you'll find [Justin Searls' talk on testing](http://blog.testdouble.com/posts/2015-11-16-how-to-stop-hating-your-tests.html) really interesting since he talks a bit about this. Checking `playState` is probably ok in some cases, but I think most of the time it's unnecessary. View on GitHub: https://github.com/w3c/web-platform-tests/pull/3327#issuecomment-238481249
Received on Tuesday, 9 August 2016 07:59:12 UTC