667
edits
Changes
Created page with 'October 20, 2012, #whatwg on freenode <pre> 14:40 < humph_> I had a question about the best way to write conformance tests for WebVTT, specifically how and where to capture meta…'
October 20, 2012, #whatwg on freenode
<pre>
14:40 < humph_> I had a question about the best way to write conformance tests for WebVTT, specifically how and where to capture metadata about the different good/bad .vtt files
14:40 < humph_> should we put them in the .vtt file's comment block, in a separate file per test, in a wiki, in one file keyed by test file, etc.
14:41 < humph_> what's the right approach?
14:41 < jgraham> zcorpan: ^
14:42 < jgraham> If it were me and I was writing a parser, I might develop a simple text format to embed the VTT and a desciption in
14:42 < zcorpan> humph_: webvtt doesn't currently support comments, so your options are in the cue text or in a separate file
14:42 < jgraham> Like we did for the HTML parser tests
14:42 -!- sicking [~chatzilla@nat/mozilla/x-qyqlmnzhabeqzbgc] has quit [Ping timeout: 240 seconds]
14:42 < jgraham> Then have a script to spit out the actual browser-readable tests
14:42 < humph_> jgraham: so a file that you'd split the .vtt out of at test time?
14:42 < jgraham> Yeah
14:43 < zcorpan> humph_: for some of my parser tests i've put json in cue data with expected settings/timings; and a separate json file with expected number of cues or "error"
14:43 < humph_> I was afraid of putting it in the cue text and making the tests unnecessarily large
14:43 < zcorpan> for my other parser tests i used html5lib style like jgraham suggested
14:44 < zcorpan> (i.e. for testing cue text parsing)
14:44 < zcorpan> i haven't released these tests but i intend to
14:44 < humph_> cool. I'm implementing webvtt in firefox with my class this term, just wanted to figure out the best way to start
14:44 < humph_> they are beginning with these tests
14:45 < zcorpan> ok
14:45 < jgraham> Nice project :)
14:45 < jgraham> And testing++
14:45 < humph_> http://vocamus.net/dave/?p=1525
14:45 < humph_> yeah, should be fun
14:45 < jgraham> I hope you will release the results to W3C for inclusion in the official testsuite
14:46 < humph_> yeah, sylvia suggested the same
14:46 < humph_> I think that's a good plan
14:46 < jgraham> sylvia++
14:46 < humph_> indeed
14:46 < humph_> alright, thanks for the ideas
14:46 < jgraham> If you need any help with test harness wrangling or getting the tests submitted feel free to ask me
14:47 < humph_> k
14:47 < humph_> I started by doing a node module to wrap the js parser
14:47 < jgraham> Or there is #testing on the W3C server
14:47 < humph_> https://github.com/humphd/node-webvtt
14:47 < humph_> so they could at least validate in a test harness
14:47 < zcorpan> i used testharness.js for testing the parser and the dom api, and reftests for rendering
</pre>
<pre>
14:40 < humph_> I had a question about the best way to write conformance tests for WebVTT, specifically how and where to capture metadata about the different good/bad .vtt files
14:40 < humph_> should we put them in the .vtt file's comment block, in a separate file per test, in a wiki, in one file keyed by test file, etc.
14:41 < humph_> what's the right approach?
14:41 < jgraham> zcorpan: ^
14:42 < jgraham> If it were me and I was writing a parser, I might develop a simple text format to embed the VTT and a desciption in
14:42 < zcorpan> humph_: webvtt doesn't currently support comments, so your options are in the cue text or in a separate file
14:42 < jgraham> Like we did for the HTML parser tests
14:42 -!- sicking [~chatzilla@nat/mozilla/x-qyqlmnzhabeqzbgc] has quit [Ping timeout: 240 seconds]
14:42 < jgraham> Then have a script to spit out the actual browser-readable tests
14:42 < humph_> jgraham: so a file that you'd split the .vtt out of at test time?
14:42 < jgraham> Yeah
14:43 < zcorpan> humph_: for some of my parser tests i've put json in cue data with expected settings/timings; and a separate json file with expected number of cues or "error"
14:43 < humph_> I was afraid of putting it in the cue text and making the tests unnecessarily large
14:43 < zcorpan> for my other parser tests i used html5lib style like jgraham suggested
14:44 < zcorpan> (i.e. for testing cue text parsing)
14:44 < zcorpan> i haven't released these tests but i intend to
14:44 < humph_> cool. I'm implementing webvtt in firefox with my class this term, just wanted to figure out the best way to start
14:44 < humph_> they are beginning with these tests
14:45 < zcorpan> ok
14:45 < jgraham> Nice project :)
14:45 < jgraham> And testing++
14:45 < humph_> http://vocamus.net/dave/?p=1525
14:45 < humph_> yeah, should be fun
14:45 < jgraham> I hope you will release the results to W3C for inclusion in the official testsuite
14:46 < humph_> yeah, sylvia suggested the same
14:46 < humph_> I think that's a good plan
14:46 < jgraham> sylvia++
14:46 < humph_> indeed
14:46 < humph_> alright, thanks for the ideas
14:46 < jgraham> If you need any help with test harness wrangling or getting the tests submitted feel free to ask me
14:47 < humph_> k
14:47 < humph_> I started by doing a node module to wrap the js parser
14:47 < jgraham> Or there is #testing on the W3C server
14:47 < humph_> https://github.com/humphd/node-webvtt
14:47 < humph_> so they could at least validate in a test harness
14:47 < zcorpan> i used testharness.js for testing the parser and the dom api, and reftests for rendering
</pre>
