2
Daniel Bostwick
cantina.co
danielbostwick.com
github.com/bostwick
linkedin.com/in/dbostwick
Senior Technical Consultant
Slide 3
Slide 3 text
3
Testing Philosophy
Slide 4
Slide 4 text
4
Testing Misconceptions
What testing is not
Slide 5
Slide 5 text
5
You Need To Test
Slide 6
Slide 6 text
6
You Need To Test
Testing is not a requirement
for a successful* project.
*depending on your definition of success.
Slide 7
Slide 7 text
7
You need 100%
test coverage
Slide 8
Slide 8 text
8
You need 100%
test coverage
100% Coverage is a great
ideal, but any coverage will
help improve a project.
Slide 9
Slide 9 text
9
Testing proves your
program is correct
or free of bugs
Slide 10
Slide 10 text
10
Testing proves your
program is correct
or free of bugs
Unless you’re using formal
verification systems, testing
can prove nothing.
Slide 11
Slide 11 text
11
Writing tests means
you can “grow” your
architecture over time,
instead of up front
Slide 12
Slide 12 text
12
Writing tests means you
can “grow” your
architecture over time,
and not make decisions
up front
If you don’t know how to
implement something to
start, following TDD will not
help you figure it out.
http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html
Slide 13
Slide 13 text
13
So, Why Write Tests?
Slide 14
Slide 14 text
If you aren’t testing, your users are.
14
Because it’s inevitable.
Slide 15
Slide 15 text
- Ronald Reagan
15
Trust, but verify.
Slide 16
Slide 16 text
16
Testing demonstrates the behavior
of software.
Slide 17
Slide 17 text
17
A test ensures that a system behavior
remains constant even as the underlying
implementation may change.
Slide 18
Slide 18 text
“If builders built buildings the way programmers wrote programs, then
the first woodpecker that came along would destroy civilization.”
- Gerald Weinberg
18
Testing inspires confidence
Slide 19
Slide 19 text
19
What should be tested?
Slide 20
Slide 20 text
20
It’s not about
Code Structure
“use strict”
module.exports = {
sayHello: function(name) {
return “Hello, “ + name;
}
};
if (require.main === module) {
console.log(sayHello(“World”));
}
Slide 21
Slide 21 text
21
It’s about
Behavior.
When I run hello.js,
I want to print “Hello, World.”
so I can have an example for this
presentation .
Slide 22
Slide 22 text
22
Behavior The way in which a system acts
in response to a particular
situation or input.
Slide 23
Slide 23 text
23
Job Story When ______________ ,
I want to _______________ ,
so I can _______________ .
Slide 24
Slide 24 text
24
Behavior is
independent of
implementation.
# This passes, too!
“use strict”
console.log(“Hello, World”);
Slide 25
Slide 25 text
25
Test Categories
Unit Tests
Integration
Tests
System Tests
Slide 26
Slide 26 text
26
How to Test?
Slide 27
Slide 27 text
jsUnit, jUnit, OCUnit, Test::Unit, PyUnit
27
xUnit You already have it.
29
Job Story When ______________ ,
I want to _______________ ,
so I can _______________ .
Slide 30
Slide 30 text
30
Behavior-Based
Test Names
function
testSayHello_givenName_returnsHelloName
function
testSayHello_givenUndefined_returnsNonsense
function
testSayHello_givenObject_returnsHelloObjectObject
http://dannorth.net/introducing-bdd/
32
Your test names should be executable
documentation.
Slide 33
Slide 33 text
33
Writing System Tests for an API
Slide 34
Slide 34 text
34
Use Cases for API System Tests
Building your own API
• Write your API documentation as
executable tests.
• Know when the API demonstrates the
required behavior for implementation.
• Provides a “definition of done.”
Integration with a 3rd-Party API
• Verify the 3rd-Party API works as the
vendor says it should.
• Expose and document any
inconsistencies between Vendor’s docs
and the actual behavior.
38
Running the
Tests
$ # From the project dir
$ ./node_modules/.bin/mocha test/**/*
# Put this in your package.json:
“scripts”: {
“test”: “./node_modules/.bin/mocha
test/**/*”
}
$ npm test
Slide 39
Slide 39 text
39
Testing the Climb Higher API
Slide 40
Slide 40 text
40
Climb Higher API
GET, PUT /user
POST /users
GET, POST /sessions
GET, PUT, DELETE /sessions/:sessionId
POST
/sessions/:sessionId/ticks
DELETE /sessions/:sessionId/ticks/:tickId
Slide 41
Slide 41 text
41
System Test Setup & Teardown
https://github.com/climbhigher/climbhigher-api/blob/master/test/climb-
higher/routes.js#L14
Slide 42
Slide 42 text
42
Simple Endpoint Test
https://github.com/climbhigher/climbhigher-api/blob/master/test/climb-
higher/routes/get-user.js
Slide 43
Slide 43 text
43
Complicated Endpoint Test
https://github.com/climbhigher/climbhigher-api/blob/master/test/climb-
higher/routes/post-session-ticks.js
Slide 44
Slide 44 text
44
Extract Common Helpers
https://github.com/climbhigher/climbhigher-api/blob/master/test/
helpers.js
Slide 45
Slide 45 text
45
What about unit tests?
Slide 46
Slide 46 text
46
Review
• Testing is not a magic silver bullet.
• Testing gives you confidence about behavior.
• Use Job Stories to define behavior.
• Name your tests based on a system’s behavior.
• It’s easy to test both your own code and other’s with System tests.
• Mocha and BDD give you readable, executable documentation.