goog.testing.TestCase
| Provided By | |
|---|---|
| All Known Direct Subclasses |
A class representing a JsUnit test case. A TestCase is made up of a number of test functions which can be run. Individual test cases can override the following functions to set up their test environment:
- runTests - completely override the test's runner
- setUpPage - called before any of the test functions are run
- tearDownPage - called after all tests are finished
- setUp - called before each of the test functions
- tearDown - called after each of the test functions
- shouldRunTests - called before a test run, all tests are skipped if it returns false. Can be used to disable tests on browsers where they aren't expected to pass.
TestCase objects are usually constructed by inspecting the global environment
to discover functions that begin with the prefix test.
(See #autoDiscoverLifecycle and #autoDiscoverTests.)
Testing asychronous code with promises
In the simplest cases, the behavior that the developer wants to test
is synchronous, and the test functions exercising the behavior execute
synchronously. But TestCase can also be used to exercise asynchronous code
through the use of
promises. If a test function returns an object that has a
then method defined on it, the test framework switches to an
asynchronous execution strategy: the next test function will not begin
execution until the returned promise is resolved or rejected. Instead of
writing test assertions at the top level inside a test function, the test
author chains them on the end of the returned promise. For example:
function testPromiseBasedAPI() {
return promiseBasedAPI().then(function(value) {
// Will run when the promise resolves, and before the next
// test function begins execution.
assertEquals('foo', value.bar);
});
}
Synchronous and asynchronous tests can be mixed in the same TestCase.
Test functions that return an object with a then method are
executed asynchronously, and all other test functions are executed
synchronously. While this is convenient for test authors (since it doesn't
require any explicit configuration for asynchronous tests), it can lead to
confusion if the test author forgets to return the promise from the test
function. For example:
function testPromiseBasedAPI() {
// This test should never succeed.
promiseBasedAPI().then(fail, fail);
// Oops! The promise isn't returned to the framework,
// so this test actually does succeed.
}
Since the test framework knows nothing about the promise created in the test function, it will run the function synchronously, record a success, and proceed immediately to the next test function.
Promises returned from test functions can time out. If a returned promise
is not resolved or rejected within promiseTimeout milliseconds,
the test framework rejects the promise without a timeout error message.
Test cases can configure the value of `promiseTimeout` by setting
goog.testing.TestCase.getActiveTestCase().promiseTimeout = ...in their `setUpPage` methods.
new TestCase( opt_name )
| Parameters |
|
|---|