IDL Test Planning Conventions (draft!)

IDL tests test that the surface of the API behaves according to the rules set by WebIDL, such as optional/required arguments, argument types, numeric ranges, and so on.

Note: Default value tests (for arguments and dictionary members) usually shouldn't be IDL tests. This is because it's quite difficult to check whether the default value was set or not. Instead, these can be incorporated into operation tests, which already do the hard work - all you have to do is make sure the behavior with undefined has the same expected result that you have for [default value].

IDL errors should throw exceptions. WebGPU errors should be checked not to occur by the fixture (TODO!).

Helpers

Helper rules for writing IDL test plans. Many of these will have helper code that implements these rules.

• tests for dictionaries
  • may have extra fields
  • for each field, if required:
    • tests for required things
  • for each field, if optional:
    • tests for optional things
• tests for required things
  • may not be omitted, null, or undefined
• tests for optional things
  • may be omitted, null or undefined, may not be false
• tests for sequences
  • may be empty
  • may be an array of one idl-valid value
  • may be an array of 10000 idl-valid values
  • may be an iterable (use a custom iterable, not Set)
• tests for range-enforced numbers
  • regardless of type, may be 0, 0.5, 100
  • IFF float, may be NaN, MAX_VALUE, -MAX_VALUE, POSITIVE_INFINITY, NEGATIVE_INFINITY
  • if int32, may be 0x7FFFFFFF+.9 but not 0x80000000
  • if uint32, may be 0xFFFFFFFF+.9 but not 0x100000000
  • if int64, may be 0x7FFFFFFFFFFFFFFFF+.9 but not 0x8000000000000000
  • if uint64, may be 0xFFFFFFFFFFFFFFFFF+.9 but not 0x10000000000000000
• tests for nullable things
  • may be omitted, undefined, or null, but not false
• tests for enums
  • may not be empty string
  • may be any value in the enum