1 of 19

Test-Driven JavaScript with

Brad Urani

Director of Engineering

​

@BradUrani

linkedin.com/in/bradurani

www.gainupside.com

​

2 of 19

http://jasmine.github.io/2.0/introduction.html

https://github.com/pivotal/jasmine

​

Inspired by RSpec

​

3 of 19

Important Terms:

Suites: a collection of tests in single file - describe

Specs - AKA tests. Test a single condition only - it

Expectation - AKA assertions, verify result - expect

Matcher - Perform comparison - .toEqual, .toBe

4 of 19

TDD vs BDD

  • TDD is a development process
  • BDD is a business + development process

5 of 19

TDD vs TFD

  • TDD - Write tests as you code
  • TFD - Write all the tests first

6 of 19

Principles of good unit tests

  • Unit tests should test only one well-defined piece of functionality
  • Unit tests should only call a single function*

​

*Your mileage may vary

​

7 of 19

8 of 19

Important Questions

  • Do we test every method?
  • Do we test private methods?
  • When is a class too big?
  • When is a function too big?

9 of 19

Integration Tests

​

  • Test the entire system, front-to-back (usually including the database)
  • Must be idempotent between runs
  • Can be powered by Jasmine making AJAX calls, or testing against local storage (Web storage, IndexedDB, Cookies)

10 of 19

Avoid the Middle Ground

11 of 19

Behavioral Testing with the ‘Page’ pattern

12 of 19

Jasmine and CoffeeScript

describe "CoffeeScript Jasmine specs", ->

it "is beautiful!", ->

expect(" your code is so beautiful"). toBeTruthy()

13 of 19

Jasmine and NodeJS

jasmine-node require("../ src/ test.js");

​

it(" does an asynchronous call", function() {

exampleAsyncCall( function( response) {

expect( response). toContain(" something expected");

done();

});

});

​

14 of 19

Jasmine and Ruby

gem ‘jasmine’

rails generate jasmine:install

jasmine init

rake jasmine:ci

​

15 of 19

Jasmine with Jenkins and PhantomJS

  • Continuous Integration Solution for Jasmine
  • Runs multiple browsers simulations!

16 of 19

Benefits

  • Fewer Bugs
  • Confidence to refactor
  • Quick feedback about defects
  • Repeatable test
  • Living / trustworthy documentation
  • Frees up manual testers for more interesting exploratory testing

​

17 of 19

Costs:

  • Time spent writing the test
  • Time spent maintaining the test
  • Waiting for the test to run
  • Having a false sense of security when an automated test is passing

18 of 19

Is it worth it?

Yes, but…

  • Strike a balance
  • 100% coverage is usually unnecessary
  • Beware testing previously written code
  • Continue to manually test
  • Maintain the Tests
  • Use Continuous Integration (CI)

19 of 19

Resources

Source: https://github.com/bradurani/ConwaysGameOfLifeJasmineDemo

​

Brad Urani

LinkedIn: http://linkedin.com/in/bradurani

Twitter: @BradUrani

Email: bradurani@gmail.com