player method related tests #26
Conversation
|
@shans @ewilligers @rjwright - As requested, please take a look. |
|
Spreadsheet looking at the results from the runs.... |
| description: "Testing player.cancel() with complex effect when the player is cancelled.", | ||
| run: function() { | ||
| for (var i = 0; i < 1000; i++) { | ||
| player.cancel(); |
There was a problem hiding this comment.
This test doesn't measure much. Once the player is cancelled, calling cancel() is basically a no-op.
There was a problem hiding this comment.
Yeah, this is the multi-player problem right? Did we decide on a solution?
There was a problem hiding this comment.
Ultimately we decided we couldn't do true black-box testing. With a test like this we can go three ways:
(1) if the test is trivial (the value isn't cached and isn't calculated) then we don't bother keeping it
(2) if the test is calculated but not cached, then we keep the test in the form this one is
(3) (this is the case for this test) if the test is cached, then we reset the cached status between calls, if possible, and test the combination of check-reset. Here, setting the source of the player back to animation voids the cancel, so doing that after player.cancel() would be appropriate.
|
I think we mainly just need to set the source of the player after cancel() across the tests. These are looking good. |
| @@ -0,0 +1,6 @@ | |||
| {% set description="calling reverse() on playing player" %} | |||
There was a problem hiding this comment.
Comment from @shans
reverse isn't a state - calling reverse is somewhat similar to setting playbackRate to -1
(but it does more work too). Change these to a test that just calls reverse() multiple times and re-run.
|
Moved the selected test to the top level directory. What should I do with the generator and related directory? |
Not ready to merge, just sending for review.