YUI recommends YUI3.
YUI 2 has been deprecated since 2011. This site acts as an archive for files and documentation.
This documentation is no longer maintained.
This example shows how to use advanced test options, which allow you to specify additional information about how a test should be run.
Each TestCase
can specify up to three different options for tests,
including tests that should be ignored, tests that should throw an error, and tests that should fail.
This example begins by creating a namespace and a TestCase
object:
This TestCase
serves as the basis for this example.
_should
Immediately after the name
of the TestCase
is defined, there is a _should
property.
This property specifies information about how tests should behave and is defined as an object literal with one
or more of the following properties: fail
, error
, and ignore
.Each of these three
is also defined as an object literal whose property names map directly to the names of test methods in the TestCase
.
This example uses all three properties:
This Test
specifies one test that should fail, six that should throw an error, and one that should be ignored.
In the fail
section, the test method testFail()
is specified as one that should fail. By adding the
property testFail
and settings its value to true, the TestRunner
knows that this test is expected to fail.
If the test were to be run without failing, it would be considered a failure of the test. This feature is useful when testing
YUI Test itself or addon components to YUI Test.
Moving on to the error
section, there are six tests specified that should throw an error. There are three different ways
to indicate that a test is expected to throw an error. The first is simply to add a property with the same name as the test method
and set its value equal to true (similar to specifying tests that should fail). In this example, the testGenericError()
method is specified this way. When specified like this, the test passes regardless of the type of error that occurs. This can be
dangerous since unexpected errors will also cause the test to pass. To be more specific, set the property value for the test method
to an error message string. When a string is used instead of the Boolean true, the test passes only when an error is thrown and that
error message matches the string. In this example, testStringError()
and testStringError2()
expect an error
to be thrown with an error message of "I'm a specific error message." If any other error occurs inside of the these methods,
the test will fail because the error message doesn't match. The last way to specify an error should occur is to create an actual error
object, which is the case with testObjectError()
, testObjectError2()
, and testObjectError3()
.
When specified in this way, a test will pass only when an error is thrown whose constructor and error message match that of the
error object.
The last section is ignore
, which determines tests that should be ignored. In this example, the method testIgnore()
is set to be ignored when the TestCase
is executed. Test in the ignore
section are specified the same way
as those in the fail
section, by adding the name as a property and setting its value to true.
The next part of the example contains the actual test methods. Since each test method is specified as having a certain behavior in
_should
, they each do something to show their particular functionality.
The first method is testFail()
, which does nothing but purposely fail. Since this method is specified as one that should
fail, it means that this test will pass:
This method uses Assert.fail()
to force the test to fail. This type of method is helpful if you are creating your own
type of assert methods that should fail when certain data is passed in.
Next, the test methods that should error are defined. The testGenericError()
method is specified as needing to throw
an error to pass. In the error
section, testGenericError
is set to true, meaning that any error causes
this method to pass. To illustrate this, the method simply throws an error:
The fact that this method throws an error is enough to cause it to pass (the type of error and error message don't matter). The next
two methods, testStringError()
and testStringError2()
are specified as throwing an error with a specific
message ("I'm a specific error message."):
The testStringError()
method will pass when executed because the error message matches up exactly with the one
specified in the error
section. The testStringError2()
method, however, will fail because its
error message is different from the one specified.
To be more specific, testObjectError()
, testObjectError2()
, and testObjectError3()
,
specified an error type (TypeError
) and an error messsage ("Number expected."):
Of the these three methods, only testObjectError()
will pass because it's the only one that throws a TypeError
object with the message, "Number expected." The testObjectError2()
method will fail because the type of error
being thrown (Error
) is different from the expected type (TypeError
), as specified in the error
section. The last method, testObjectError3()
, also fails. Though it throws the right type of error, the error message
doesn't match the one that was specified.
The last method in the TestCase
is testIgnore()
, which is specified to be ignored. To be certain, this
method pops up a message:
If this test weren't ignored, then the alert should be displayed. Since it is ignored, though, you will never see the alert. Additionally,
there is a special message displayed in the TestLogger
when a test is ignored.
With all of the tests defined, the last step is to run them. This initialization is assigned to take place when the document tree has been
completely loaded by using the Event utility's onDOMReady()
method:
Before running the tests, it's necessary to create a TestLogger
object to display the results (otherwise the tests would run
but you wouldn't see the results). After that, the TestRunner
is loaded with the TestSuite
object by calling
add()
(any number of TestCase
and TestSuite
objects can be added to a TestRunner
,
this example only adds one for simplicity). The very last step is to call run()
, which begins executing the tests in its
queue and displays the results in the TestLogger
.
All YUI 2.x users should review the YUI 2.8.2 security bulletin, which discusses a vulnerability present in YUI 2.4.0-2.8.1.
Copyright © 2013 Yahoo! Inc. All rights reserved.