Update ResourceTiming style guide to explain asserts vs. errors

In ResourceTiming Web Platform Tests, we want to use assertion failures
to indicate divergence from the spec but use exceptions to indicate
issues with the test code.

This change updates the style guide to call out this goal.

Bug: 1171767
Change-Id: If9df3b05de75cbb516bc5c9f1ac0897abac0b4ab
GithubIssue: w3c/resource-timing#254
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2707184
Commit-Queue: Tom McKee <[email protected]>
Reviewed-by: Yoav Weiss <[email protected]>
Reviewed-by: Steve Kobes <[email protected]>
Cr-Commit-Position: refs/heads/master@{#856285}

resource-timing/CodingConventions.md

@@ -50,10 +50,16 @@ with recurring patterns.
         web performance APIs, in general).
 *   Prefer [`fetch_tests_from_window`][3] to collect test results from embedded
     iframes instead of hand-rolled `postMessage` approaches
+*   Use the [`assert_*`][4] family of functions to check conformance to the spec
+    but throw exceptions explicitly when the test itself is broken.
+    *    A failed assert indicates "the implementation doesn't conform to the
+         spec"
+    *    Other uncaught exceptions indicate "the test case itself has a bug"
 *   Where possible, we want tests to be scalable - adding another test case
     should be as simple as calling the tests with new parameters, rather than
     copying an existing test and modifying it.
 
 [1]: https://www.w3.org/TR/resource-timing-2/
 [2]: https://web-platform-tests.org/writing-tests/testharness-api.html#promise-tests
 [3]: https://web-platform-tests.org/writing-tests/testharness-api.html#consolidating-tests-from-other-documents
+[4]: https://web-platform-tests.org/writing-tests/testharness-api.html#list-of-assertions