A little background on TDD and BDD

I won’t go deep into Test Driven Development (TDD) theory since it’s a bigger subject than I can cover in this article. Many articles on the web go into detail on the subject. What’s important here are the basics of the process and of how they relate to BDD. BDD uses TDD as a starting point, and then takes it a few steps further.

TDD emphasizes writing unit tests (ideally) at the beginning of the application development process to help the developer design the code. Essentially designing your object and method interfaces through the test, and refactoring the code and tests and the code matures. The tests are often written as a white box test- inside-out which tests the specific implementation of a piece of code.

In a nut-shell, TDD suggests the user take the following steps when developing:

1. Before any coding starts, write a test to design the code against a specification.
2. Run the test. The test fails because there isn’t any code in place to support the code.
3. Write some code.
4. Test.
5. Refactor.
6. Test again and fix bugs and implementation.

BDD is an agile software development technique that also emphasizes writing unit tests. A difference is that instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in. In doing so, test authors focus on why a piece of code is necessary, and what its goal is.

Test Syntax

A sample QUnit test case looks like the following code:

// your applications custom code function addValues( a, b ) {     return a + b; }; // the QUnit test code test("test addValues(a, b) function", function() {     equal(addValues( 1, 2), 3, "1 + 2 = 3" );     equal(addValues( 1.75, 2), 3.75, "1.75 + 2 = 3.75" );     notEqual(addValues( 1, 2), "3", "1 + 2 != '3' as a String"); });

A sample Jasmine test case is written as follows:

// your applications custom code function addValues( a, b ) {     return a + b; }; // the Jasmine test code describe("addValues(a, b) function", function() {     it("should equal 3", function(){         expect( addValues(1, 2) ).toBe( 3 );     });     it("should equal 3.75", function(){         expect( addValues(1.75, 2) ).toBe( 3.75 );      });     it("should NOT equal '3' as a String", function(){         expect( addValues(1, 2) ).not.toBe( "3" );     }); });

Notice both Qunit and Jasmine are testing the same things. But the Jasmine approach is easier to read, even for someone who does not know JavaScript. And if you have written Agile user stories, the structure of the test narrative also looks familiar, similar to the standard Agile user story format:

As an <actor> I want to <action> so that <achievment>

source : http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html