All of the examples I can share are currently in the documentation or included as part of the YUI download (check the tests directory in the ZIP file).

If you’re testing a lot of interaction on a page, then I usually suggest loading YUI Test onto the actual page and running the tests there. That way, you don’t have to worry about stubbing out certain pieces of the page to things working.

Thanks for your insightful comments. Indeed, there are many schools of thoughts surrounding test methodology, and you’ve touched on a few of them. I’d just like to clarify a couple of the points.

Making the assertion failure message a statement of what should be happening isn’t redundant, it’s explanatory of what just happened. The test name and the failure message may be similar, and in this case are because the test is so simple; however, they may be very different if there are a number of assertions contained within the test.

My recommendation for setting up test suites and test cases is to get people started. I’m not saying that every method should have one test, I’m saying that every method should have a test case containing tests that explore each input-output set that you have. The point is to have a logical structure that maps directly to the objects that you are programming.

I hope this clarifies some of the points; thanks for your comments.

In an object-oriented language like JavaScript, each method is considered to be a unit

Personally prefer thinking of a class as a unit. The class provides me some behavior and I want to explain that behavior through my tests. Going at a method level seems that we are drilling into the implementation in some sense.

unit tests should test inputs and outputs

I would prefer if the you qualifies your style of unit testing as state based unit testing. There is a different school of unit testing which believes in interaction based testing. Where its not so much about the output in terms of return values, changes in the state of variables, or thrown errors. The focus is on the interaction (method calls) with it’s collaborators.

In YUI Test, failure message is always the last argument of any assertion method

They seem to have broken the xUnit convention. in xUnit failure message is always the first argument.

You claims:

//Bad failure message
YAHOO.util.Assert.areEqual("Hello world", result, "The result wasn't 'Hello world'");

//Good failure message
YAHOO.util.Assert.areEqual("Hello world", result, "Leading white space should be stripped.");

While I agree with you that the second example is better than the first one, but I think the failure message in the second case is redundant. If you look at the whole test method below,

testTrimWithLeadingWhiteSpace: function(){
var result = trim(" Hello world");
YAHOO.util.Assert.areEqual("Hello world", result, "Leading white space should be stripped.");
}

The method name already tells you that leading white space should be trimmed or stripped out. In this specific case I would not give any failure message. If its your company’s best practice to give one, then I would rather prefer your failure message as “Leading white space was not stripped”

Functional tests, on the other hand, cannot exist ahead of time because they are so tied to the user interface and how it changes in response to user interaction.

This is not always true. In a lot of cases you can actually write your functional or acceptance tests before you create any code. Refer to Acceptance Test Driven Development

Create one test suite for every object you’re going to test

Why is this important? I don’t see how this will help?

Create one test case for every method of an object you’re going to test and add it to the object’s test suite.

I would rather create a test class per important entity in my production code and write one test method per behavior the class fulfills. Sometimes I might have more than 1 test for one method and sometimes none. I’m not sure if I would create a guideline saying every method should have one test.