mirror of https://github.com/tc39/test262.git
Update {CONTRIBUTING,INTERPRETING}.md per @jugglinmike's feedback
This commit is contained in:
parent
b9daa57dcb
commit
c59f671bda
|
@ -231,6 +231,8 @@ assert.throws(TypeError, function() {
|
|||
});
|
||||
```
|
||||
|
||||
Consumers that violate the spec by throwing exceptions for parsing errors at runtime instead of at parse time can still get value out of Test262's negative tests by conditionally overriding `$DONOTEVALUATE` to be a no-op for tests that are known to fail. This way, the consumer can still verify that they throw an exception of the expected type, even if it happens during the wrong phase, which prevents regressions and further deviations from the spec.
|
||||
|
||||
## Writing Asynchronous Tests
|
||||
|
||||
An asynchronous test is any test that include the `async` frontmatter flag. When executing such tests, the runner expects that the global `$DONE()` function will be called to signal test completion.
|
||||
|
|
|
@ -103,6 +103,8 @@ properties of the global scope prior to test execution.
|
|||
sleeps the execution for approximately that duration.
|
||||
- **`monotonicNow`** - a function that returns a value that conforms to [`DOMHighResTimeStamp`][] and is produced in such a way that its semantics conform to **[Monotonic Clock][]**.
|
||||
|
||||
In addition, consumers may choose to override any of the [the available test harness helper functions](https://github.com/tc39/test262/blob/master/CONTRIBUTING.md#test-environment) as they see fit. See [the documentation on handling errors and negative test cases](https://github.com/tc39/test262/blob/master/CONTRIBUTING.md#handling-errors-and-negative-test-cases) for a useful example of this.
|
||||
|
||||
|
||||
#### Normative references
|
||||
|
||||
|
|
Loading…
Reference in New Issue