Note: FuncUnit Roadmap

The FuncUnit Getting Started guide is a quick walkthrough of creating and running a test.

Set up a test

[http://docs.jquery.com/Qunit QUnit] provides the basic structure needed to write unit or functional tests.

Module

[http://docs.jquery.com/QUnit/module#namelifecycle Modules] are groups of tests with setup and teardown methods that run for each test.

module("Contacts", {
  // runs before each test
  setup: function(){
    // setup code
  },
  // runs after each test
  teardown: function(){
    // cleanup code
  }
})

Test

test("findOne", function(){
  // define a test
})

Assertions

test("counter", function() {
  ok(Conctacts.first().name, "there is a name property");
  equal(Contacts.counter(), 5, "there are 5 contacts");
});

Open a page

The following uses F.open( URL ) to open autocomplete.html before every test.

module("autosuggest",{
  setup: function() {
    F.open('autosuggest.html')
  }
});

Calling open on window will cause FuncUnit commands to operate on the current window. This is also the default if you don't open any page.

Query for elements

FuncUnit tests are written just like jQuery. The [funcunit.finding S method] is a copy of jQuery, which queries for elements in the application page. Like $, FuncUnit methods are chainable on the results of F.

// grab the #description element, wait for it to be visible, type in it
F("#description").visible().type("Test Framework")

Simulate user actions

When you're testing a widget, you need to simulate the [funcunit.actions actions] that a user takes. FuncUnit uses the [syn] library to accurately simulate the correct low level events like mouseup and keypress for high level actions like [FuncUnit.prototype.click] and [FuncUnit.prototype.type]. The following shows how to simulate common user actions.

Click

// click a button
F('#submit_button').click()

Type

// type in an input
F('#task_name').type("Learn FuncUnit")

Drag

// drag a task item to the trash area
F('.task').drag(".trash");

Wait for page conditions

After a user action, your test page's event handlers run and the page is changed. Wait commands are used to wait for some page condition before continuing.

Waits are overloaded jQuery getter methods. F.fn.text( textVal, callback ) waits for an element's $.fn.text to match the textVal.

// wait for result to show "task complete"
F("#result").text("task complete")

Visible

// wait for first result to be visible
F('#autocomplete_results:first-child').visible()

Width

// after clicking a menu item, wait for its width to be 200px
F('#horizontal_menu_item').width(200)

Val

// wait for the input value
F('#language_input').val("JavaScript")

Size

// wait for number of matched elements
F('.contact').size(5)

There are many more [funcunit.waits waits] possible.

Get information and run assertions

After simulating an action and waiting for the page to change, you often want to get information about an element and run assertions. You can use jQuery getter methods in combination with QUnit assertions.

These methods (which return synchronous results) are used in callbacks that run after a wait method completes.

// wait until we have some results, then call the calback
F('.autocomplete_item').visible(function(){
  equal( F('.autocomplete_item').size(), 5, "there are 5 results")
})

Running in browser

These tests can be loaded in any browser. The app page opens in a separate window and results show up in the QUnit page.

test("JavaScript results",function(){
  F('input').click().type("JavaScript")

  // wait until we have some results
  F('.autocomplete_item').visible(function(){
    equal( F('.autocomplete_item').size(), 5, "there are 5 results")
  })
});