1.
Jörg Henning
@JoergHenning

2.
Software Testing
Express, Mocha, Chai

3.
Why?
● Working software
● Intended functionality
● No bugs
● No downtimes
● No security issues
● Extensible, easy to extend & modify
(because we need to pivot)

4.
Production Testing?
Your User
● “Negative Features”
● Bad reviews
● Users leave
● RIP Unicorn ♱

5.
QA in the end
Feature A
Feature B
Feature C
QA + Bug Fixing
???

6.
Agile Software Development

7.
Technical Debt

8.
Node.js release timeline

9.
ES2015/ES6
● arrows
● classes
● enhanced object literals
● template strings
● destructuring
● default + rest + spread
● let + const
● iterators + for..of
● generators
● unicode
● modules
● module loaders
● map + set + weakmap + weakset
● proxies
● symbols
● subclassable built-ins
● promises
● math + number + string + array + object APIs
● binary and octal literals
● reflect api
● tail calls
(see https://github.com/lukehoban/es6features)
Also check out http://node.green/!

10.
Fear!

11.
Test Automation

12.
Manual Testing
// test_multiply.js
var multiply = require('./multiply');
var theMeaning = multiply(6, 7);
console.log(theMeaning);
> node test_multiply.js
42

13.
npm install -g mocha

14.
Mocha
var assert = require('assert');
var multiply = require('./multiply');
describe('multiply', () => {
it('should return 42 for 6 * 7', () => {
var theMeaning = multiply(6, 7);
assert.equal(theMeaning, 42);
});
});

15.
npm install chai --save-dev

16.
Chai
var expect = require(‘chai’).expect;
var multiply = require('./multiply');
describe('multiply', () => {
it('should return 42 for 6 * 7', () => {
expect(multiply(6,7).to.equal(42));
});
});

17.
Chai - Styles
● Assertion style:
○ require(‘chai’).assert => assert.equal(expected, actual);
○ Similar to built in assert, but more assertions
○ E.g.: assert.typeOf(), assert.lengthOf()
● BDD Style
○ require(‘chai’).expect => expect(actual).to.equal(expected);
○ require(‘chai’).should() => actual.should.equal(expected); // don’t do!
○ E.g.: expect(x).to.be.null; expect(obj).to.be.instanceOf(ctor); expect(foo).
to.not.equal(bar);
Full API: http://chaijs.com/api/

18.
Source: https://www.simple-talk.com/sql/database-delivery/what-is-behaviour-driven-(database)-development/

19.
Good tests are:
● Fast - milliseconds!
● Small - test only a single piece of functionality at a time
● Simple - complexity = less reliability
● Plentiful - several tests per feature
● Isolated - have no dependencies between each other
● Readable - other people will need to read them too
● Clean - same code quality as the software they are testing

20.
TDD/BDD
The two rules of TDD:
● Don’t write a single line of code unless you have a failing automated test
● Eliminate duplication
How to?
● Write a small test (and watch it fail)
● Make the test work (quick & dirty)
● Eliminate duplication (refactor)
Behaviour Driven Development (also ATDD):
● Similar to TDD for higher level tests
● Readable by Product Owners, Business Analysts, etc.

21.
BDD
Feature: Listing command
In order to change the structure of the folder I am currently in
As a UNIX user
I need to be able see the currently available files and folders there
Scenario: Listing two files in a directory
Given I am in a directory "test"
And I have a file named "foo"
And I have a file named "bar"
When I run "ls"
Then I should get:
"""
bar
foo
"""
http://docs.behat.org/en/v3.0/ (PHP)
https://cucumber.io/ (Rails)

22.
https://github.com/joerx/expensely
fork, clone
git reset --hard v0.6.2