Changes

Jump to: navigation, search

0.1 Release 2012 WebVTT Test Suite

2,633 bytes added, 18:22, 27 September 2012
→‎Tests
In order to write our parser, we'll need a way to prove it's correct as per the spec. Doing so involves the creation of a spec conformance test suite, consisting of good and bad WebVTT files. Each test file makes sure that a particular part of the spec is true, and forces the parser to do various things.
 
The [http://www.w3.org/QA/WG/2005/01/test-faq#why W3C defines Conformance Testing] as follows:
 
<blockquote>Focuses on testing only what is formally required in the specification in order to verify whether an implementation conforms to its specifications. Conformance testing does not focus on performance, usability, the capability of an implementation to stand up under stress, or interoperability; nor does it focus on any implementation-specific details not formally required by the specification.</blockquote>
 
They [http://www.w3.org/QA/WG/2005/01/test-faq#good go on to say] that good tests are:
 
* Mappable to the specification (you must know what portion of the specification it tests)
* Atomic (tests a single feature rather than multiple features)
* Self-documenting (explains what it is testing and what output it expects)
* Focused on the technology under test rather than on ancillary technologies
* Correct
When writing test files, remember that each test should test only one thing. Make them simple, small, and discrete. All you're doing is writing a WebVTT file with enough data in it to trigger a rule in the parser.
 
Also make sure you capture metadata about your test. What is it testing? Which part(s) of the spec? How did you generate the file? See http://lists.w3.org/Archives/Public/public-texttracks-contrib/2012Aug/att-0000/webvtt_test_cases.html.
== Example ==
** Install the webvtt npm module:
$ sudo npm install -g webvtt
* Add humphd's webvtt github repo as a remote
* Switch to the seneca branch
$ git checkout seneca
* Add your tests to test/spec/good and test/spec/bad
== Tests ==
What follows is a list of We'll break the tests we need, followed up by type within the name file format specification. Each group will be responsible for determining tests for their section of the person doing spec. The sections, while somewhat arbitrary (i.e., feel free to further subdivide or offer other divisions) are: # [[General File Structure]]# [[Cues IDs]]# [[Cue Times]]# [[OSD600/webvtt/cue_settings|Cue Settings]]# [[Cue Text, including replacements]]# Text Tags, Text and CSS Each group is responsible for determining and writing the tests necessary for their section, and can be listed below, or in a separate wiki page. Every section/test needs to be owned so itdoesn't get lost. ===Test Naming Format=== http://zenit.senecac.on.ca/wiki/index.php/Test_files == Open Questions ==
''* Which metadata should we capture about each test?* Which format should we use for this metadata?** Should we embed in the WebVTT comment block?** Should we have test-file.vtt and test-file.vtt.html (i.e., 2 files per test, one with metadata)?** Should we have one large file with data about the tests go herein the folder?** Should we write code/build steps to generate metadata from webvtt files? (e.g., extract from header of test file, merge secondary files into one file, etc.)** I asked this of the #whatwg channel on freenode, where the W3C spec editors hang out.[[WebVTT Testing Question on #whatwg|Their answer is here]].''
== Resources ==
* [https://github.com/humphd/node-webvtt node-webvtt repo] (CLI version of [http://quuz.org/webvtt/ online webvtt validator])
* [http://lists.w3.org/Archives/Public/public-texttracks-contrib/2012Aug/0000.html Contributing back to W3C]
* [http://www.w3.org/QA/WG/2005/01/test-faq W3C Test FAQ]
* UTF-8 Compatible Editors (make sure you are loading/saving UTF-8):
** http://www.sublimetext.com/
** http://notepad-plus-plus.org/
Errichard
1
edit
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/wiki/Special:MobileDiff/87901...88867"

Navigation menu