The Rails plugin gives you generators when using Screw Unit in a Rails environment.

Running Screw Unit Server

First you need to start your Screw Unit server.

If you are using screw_unit_server as a Rails plugin, you can simply run:
script/screw_unit_server

If you are using the screw_unit gem, you can run:
screw_unit_server /path/to/your/javascript/spec/files /path/to/your/javascript/implementation/files

Once the server is started, there are two possibly ways to run your js spec:

Open your browser to http://localhost:8080/specs

Start the Selenium server by running selenium from the command line, then running screw_unit from the command line

Screw Unit on CI

JS spec uses the Selenium gem to automatically control browsers on different machines.

To use Screw Unit in a CI environment,

Install and run the selenium RC server on the machine that you want to run the browsers by using the command:
selenium

Run the screw_unit_server on the machine that has the files.
script/screw_unit_server

Run the screw_unit client. The screw_unit client has --selenium_browser_start_command, --selenium_host, --selenium_port, and --spec_url arguments to specify
where the Selenium server is relative to the screw_unit server, and where the screw_unit server is relative to the browser.

The Runner

Global Befores and Afters

A global before is a before block run before all tests in a test suite, regardless of their nesting. This is often useful to reset global variables, or blank-out DOM nodes before each test is run. Put this at the top of the your suite file or in your spec helper.

Screw.Unit(function() {
before(function() { ... });
});

Note that you can have any number of Screw.Unit(...) blocks in one file. Thus, you can have multiple global befores and afters.

Custom Matchers

A custom matcher is a custom assertion specifically tailored to your application. These are helpful in increasing the readability and declarativity of your tests. To create a custom matcher, fill in the blanks for this code:

The models and views directories are here only for comparison. As a general rule, mirror the file structure of your source code in your spec directory. For example, if you have an MVC application and you organize your source code into models, views, and controllers directories, have parallel directories in your spec/ directory, with tests for your models, views, and controllers in their respective directories.

Writing Good Tests

A great test maximizes these features:

it provides documentation, explaining the intended functioning of the system as well as how the source code works;

it supports ongoing development, as you bit-by-bit write a failing test and make it pass;

it supports refactoring and prevents regression;

and it requires little modification as the implementation of the system changes, especially changes to unrelated code.

This section focuses principally on tests as documentation. To provide documentation, as well as support future modification, a test should be readable and well organized. Here are some recommendations on how to do it.

Use Nested Describes to Express Context

Often, when you test a system (a function, an object), it behaves differently in different contexts. Use nested describes liberally to express the context under which you make an assertion.

describe("Caller#prioritize", function() {
describe("when there are two callers in the queue", function() {
describe("and one caller has been waiting longer than another", function() {
...
});
});
});

In addition to using nested describes to express context, use them to organize tests by the structural properties of your source code and programming language. In Javascript this is typically prototype and function. A parent describe for a prototype contains nested describes for each of its methods. If you have cross-cutting concerns (e.g., related behavior that spans across methods or prototypes), use a describe to group them conceptually.

In this example, one parent describe is used for all Car behavior. There is a describe for each method. Finally, cross-cutting concerns like callbacks and logging are grouped because of their conceptual affinity.

Test Size

Individual tests should be short and sweet. It is sometimes recommended to make only one assertion per test:

it("chooses the caller who has been waiting the longest",function(){expect(Caller.prioritize()).to(equal,caller_waiting_the_longest);});

According to some, the ideal test is one line of code. In practice, it may be excessive to divide your tests to be this small. At ten lines of code (or more), a test is difficult to read quickly. Be pragmatic, bearing in mind the aims of testing.

Although one assertion per test is a good rule of thumb, feel free to violate the rule if equal clarity and better terseness is achievable:

Preconditions

It is ideal, if there is any chance that your preconditions are non-obvious, to make precondition asserts in your test. The last example, were it more complicated, might be better written:

it("decrements the luck field by the given amount",function(){expect(man.luck()).to(equal,5);man.decrement_luck(3);expect(man.luck()).to(equal,2)});

Whitespace, as seen here, can be helpful in distinguishing setup and preconditions from the system under test (SUT) and its assertions. It is nice to be consistent in your use of whitespace (e.g., "always follow a group of preconditions by a newline"). But it is better to use whitespace as makes the most sense given the context. As with everything in life, do it consciously and deliberately, but change your mind frequently.

Behavioral Testing

Behavioral testing, that is, asserting that certain functions are called rather than certain values returned, is best done with closures. The dynamic nature of JavaScript makes mocking frameworks mostly unnecessary.

describe("something that manipulates the DOM",function(){it("is effortless to test!",function(){vardom_test=document.getElementById('dom_test');dom_test.innerHTML='awesome';expect(dom_test.innerHTML).to(equal,'awesome');});});

A Javascript library like jQuery, Prototype, or YUI is a essential for testing events.

Implementation Details

Screw.Unit is implemented using some fancy metaprogramming learned from the formidable Yehuda Katz. This allows the describe and it functions to not pollute the global namespace. Essentially, we take the source code of your test and wrap it in a with block which provides a new scope:

Furthermore, Screw.Unit is implemented using the Concrete Javascript style, which is made possible by the Effen plugin and jQuery. Concrete Javascript is an alternative to MVC. In Concrete Javascript, DOM objects serve as the model and view simultaneously. The DOM is constructed using semantic (and visual) markup, and behaviors are attached directly to DOM elements. For example,