developer toolbox » javascript

root@dev-upstream-client:~/devel/git/upstream/google# svn checkout http://doctype.googlecode.com/svn/ doctype

http://www.jsunit.net/

http://github.com/pivotal/jsunit

JsUnit is a Unit Testing framework for client-side (in-browser) JavaScript. It is essentially a port of JUnit to JavaScript. Also included is a platform for automating the execution of tests on multiple browsers and mutiple machines running different OSs. Its development began in January 2001.

• JsUnit's is hosted on GitHub. If you would like to contribute to JsUnit, please do so by forking the repository and issuing a pull request.
• The central area for discussion of JsUnit is a mailing list/posting area hosted by Yahoo (founded 5/17/2001). To join click here.
• If you would rather email me with questions, suggestions, problems, etc., my address for JsUnit-related correspondence is edward@jsunit.net.
• There is a public Pivotal Tracker project for JsUnit.
• There is a high-level PowerPoint introduction to JsUnit here.

jasmine javascipt TDD/BDD framework¶

Why Another JavaScript TDD/BDD Framework?¶

There are some great JavaScript testing frameworks out there already, so why did we write another?

None of the existing frameworks quite worked the way we wanted. Many only work from within a browser. Most don't support testing asynchronous code like event callbacks. Some have syntax that's hard for JS developers or IDEs to understand.

So we decided to start from scratch.

Enter Jasmine¶

Jasmine is our dream JavaScript testing framework. It's heavily influenced by, and borrows the best parts of, ScrewUnit, JSSpec, JSpec, and of course RSpec.

Jasmine was designed with a few principles in mind. We believe that a good JavaScript testing framework:

• should not be tied to any browser, framework, platform, or host language.
• should have idiomatic and unsurprising syntax.
• should work anywhere JavaScript can run, including browsers, servers, phones, etc.
• shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
• should play well with IDEs (e.g. test code should pass static analysis).

Some of our goals while writing Jasmine:

• it should encourage good testing practices.
• it should integrate easily with continuous build systems.
• it should be simple to get started with.

The result is Jasmine, and we love test-driving our code with it. Enjoy.

http://code.google.com/p/js-test-driver/wiki/DesignPrinciples

Overview

JsTestDriver is to unit-tests what Selenium is to end-to-end tests. The goal of JS Test Driver is to make JavaScript unit test development as seamless as and easy as Java unit tests.

Features

• Support TDD development model
• Super fast test execution
• Super easy set up
• Seamless integration with existing IDEs
• Debugger Support
• Federated test executions across all browsers and platforms
• Focus on the command line and the continuous build
• Designed to be farm friendly
• HTML Loading Support

Support TDD development model¶

Test-Driven-Development encourages to write lots of small focused tests and run them often. The goal of JsTestDriver was to enable the execution of the complete test suite on each save. This places severe constraints on latency. The goal was to enable the running of large (hundreds/thousands) of tests in under one second. If I am working in an IDE I save my files often. This means that as a user I can only tolerate a second or two for my tests results to come back.

Traditional test frameworks fall short of this goal. First it is not possible to run all tests in interactive mode. The reason is that each test case consist of HTML file and a collection of tests (usually around 10). The developer then loads the HTML into the Browser. To run the tests you have to refresh the browser. The Browser then reloads, reparses all of the resources and executes only the tests in this test case. Therefore as a developer I can only run one test case at a time. This implies that it is easy to break other test cases and not notice it until you check it in and the continuous build runs all of the tests cases in your tests suite. Constant refreshing of the browser also breaks the development flow, and makes it that the developer does not run the tests often.

In contrast JsTestDriver runs all of the tests every time you save.
Super fast test execution

If we wish to execute all of the tests in under one sec we have to rethink the way the tests are run. Lets see where the latency of running tests comes from in traditional test frameworks:

• Start up of browser can take several seconds
• Constant reloading of the HTML test files causes the reloading of all of the resources which puts strain on the network.
• If the resource is JavaScript than reload also implies the re-parsing of the JavaScript AST

We designed the JsTestDriver for speed from ground up. To achieve super fast execution times JsTestDriver consist of server and client code. The server captures any number of web browsers and keeps them "hot" and ready for test execution. The browser loads and parses the HTML file only once. The original HTML file contains code which turns the browser into a slave listening on the server for commands to execute. Each browser then evals any code which the server sends a request for. The server then loads your production and tests code and runs the tests for you. If you change any code the server only loads the changed code into the browser. This greatly lowers the amount of reparsing which the browser needs to do. Additionally the server is eager and it loads the code aggressively into the browser even before it is ready to run. Because the browser and their documents with your application and test code are long lived running tests is in the millisecond range. Allowing JsTestDriver to finish the whole test suite in sub-second times.
Super easy set up

Writing a test should be as simple as:

1. start the JsTestsDriver
2. write test
3. write production code. The test running should be automatic on each save.

In contrast traditional test frameworks require you to write an HTML file. This file needs to contain JavaScript dependencies to the framework, production code and tests. This means that each HTML file has a complex project dependent set up. Most developers tend to solve this by cutting and pasting the initialization files between the HTML test files.

In contrast JsTestDriver does not require any HTML file to be written by the developer. It really is as easy as writing your tests in JavaScript format.
Seamless integration with existing IDEs

Traditional test frameworks don't play nice with the IDEs. This is because they do not run in the IDE but in the browser. The context switch does not seem like a lot but it is enough to make the process clunky. Our goal is to be able to right-click on the test in the IDE and run it from within the IDE in isolation (not possible now) or as part of the whole test suite (not possible now) and have the results report inside the IDE UI (not possible now) where you can directly click on the stack trace and go to the source of the exception (again not possible with existing tools).

JsTestDriver consist of a client and a server. The server can run anywhere, but usually on the same machine. The client on the other hand is an embedable code which can be run from command line or from within any tool, such as an IDE.
Debugger support

Each browser has an existing debugger support. Our goal with JsTestDriver is to make sure that we do not break any of the existing debugger workflows and that you can place breakpoint in your production or test code.
Federated test executions across all browsers and platforms

Traditional JavaScript test frameworks run inside of a single browser. This means that each developer can run the code only in one browser at a time. This means that most tests are not run on most browsers most of the time. To make the matters worse the developer usually only has a single platform available at a time, which further complicates the problem.

In JsTestDriver the server can capture any number of browsers from any number of machines and any number of platforms. We can even have multiple versions of the same browser captured at a same time. When tests are run they are executed on all browsers in parallel. This means that when the developer runs the tests the answer will include the pass or fail information from all of the browsers at once. This means that you can easily compare browser (miss)behavior.
Focus on the command line and the continuous build

Most traditional test frameworks focus on running the tests and forget that tests need to be run in automated fashion in the continuous build machine. The biggest problem being how do I get the result of my tests out of the browser and in to a JUnit compliant XML file. Often times developers write a JUnit target which starts Selenium and controls the HTML tests runner. Java then uses selenium to load individual HTML files and records the pass fail information. This is extremely slow, not to mention backwards. Why do I need to write Java code to run JavaScript tests?
Designed to be farm friendly

JsTestDriver is designed with farm availability in mind. The JsTestDriver server can run anywhere. This means that you can have a large pool of servers running all configured with the right browser and ready to run the tests for any developer. This will greatly help with the continuous build machines ability to execute the tests across multiple platforms. It will also enable the teams to easily set up continuous builds.