This webinar will cover everything you need to know to do Continuous Integration and Continuous Deployment with Node.JS and MongoDB. It will cover topics such as how to choose a Node.JS testing / assertion framework (nodeunit, mocha, chai), integration testing with large data sets, engineering best practices to make it easier to do CI from your app, and more. By the end of this webinar, you should have a good idea of how to go about robust automated testing of your MongoDB application, including handling of failure cases such as replica sets, auto-reconnect, etc. You should also have a good idea how to tweak your testing environment for maximum MongoDB performance. We'll also talk about various general tips for using Node.JS with MongoDB.

1. CI with Node.JS
and MongoDB
© Niall O’Higgins niallo@frozenridge.co
https://github.com/FrozenRidge/node-mongodb-ci-webinar

2. Continuous Integration with Node
We define CI as “automatically running a test
suite on each commit to a VCS and reporting
success and failure”
● CI requires you to have a test suite
● Node makes it easy to specify a test suite
● NPM encourages you to have one

3. Create Node.JS Project w/ Tests
Live coding!
1.
2.
3.
4.
`npm init` in empty directory
Hit return on prompts
Run `npm test`
What happens?

4. Testing in Node.JS
Our empty new project’s test suite fails
Let’s write a test suite!
But first we should talk a little about writing
tests in Node.JS

5. Testing in Node.JS
What is a test suite? A test suite consists of:
● Test Runner
● Assertion Library
● Tests

6. Node Test Runners
A Test Runner simply runs your test suite and
reports results.
● Gives structure to your test suite
● Could be just a shell or Node script
● You can roll your own or use something offthe-shelf

7. Node Test Runners
Some Popular Node.JS Test Runners:
● Mocha
● Nodeunit
● Node-Tap
● Vows

8. Node Test Runners
We like to use Mocha. It works in the browser
and Node. It has many reporting formats.
You should feel free to choose whichever suits
you best.

9. Node.JS Assertion Libraries
An Assertion Library is used to compose
predicates which make up each test.
●
●
●
●
`if` and `throw`
Node ‘assert’ module in stdlib
ChaiJS
ShouldJS

10. Assertion Styles: TDD vs BDD
Mostly matter of emphasis and preference
BDD = more “English-like” assertions
expect(myVar).to.equal(“hello”)
TDD = more “code-like” assertions
assert.equal(myVar, “hello”)

11. Assertion Style: TDD vs BDD
BDD:
expect(myArray).to.have.length(3)
TDD:
assert.equal(myArray.length, 3)

12. Assertion Style: TDD vs BDD
We use ChaiJS as our Assertion Module as it:
● supports both TDD and BDD styles.
● has many convenient assertions.

13. Create Node.JS Project w/Tests
Let’s return to our Node.JS project.
We shall create a test suite with Mocha and
Chai.
1. `npm install --save-dev mocha chai`
2. Change tests (
)
`sed -i -e 's/echo.*/./node_modules/.bin/mocha"/g' package.json`

14. Create Node.JS Project w/Tests
Now if you run `npm test` mocha should start
There are no tests, so there are no errors.
Let’s create a test!

15. Create Node.JS Project w/Tests
But we haven’t said what we’re testing!
Let’s test a function that:
Returns whether the string ‘tdd’ exists in an
argument.

16. Create Node.JS Project w/Tests
1. Create a file named `test/test_index.js`
2. It should have the following contents:
var expect = require(‘chai’).expect
var isTdd = require(‘../index.js’).isTdd
describe(‘#index’, function() {
it(‘should return false if string tdd is not in argument’, function() {
var s = “just bdd here”
expect(isTdd(s)).to.be.false
})
})

17. Create Node.JS Project w/Tests
1. Run tests
2. They fail!
3. No implementation

18. Create Node.JS Project w/Tests
Add implementation in file “index.js”:
module.exports = {
isTdd: function(s) {
return s.indexOf('tdd') !== -1
}
}
Finally tests pass!

19. Node.JS Project w/ MongoDB
That’s very silly, basic TDD / BDD in Node.
Enough to get the idea.
Now let’s talk about MongoDB and do some
coding!
[ Finished code at https://github.com/FrozenRidge/ci-node-mongodb-test ]

20. Node.JS & MongoDB User Store
We shall create a user object store interface.
Users can be retrieved by username or email.
To test this, we write an integration test which
talks to MongoDB.

21. MongoDB Data Fixtures
We see there is a problem, in that to test
correct behaviour we must load data (aka
fixtures) into MongoDB.
We can do this in Mocha using “before” and
“after” phases.

22. Make MongoDB URL Configurable
MongoDB URI should be configurable via
environment variable - see 12factor.net
e.g. process.env.MONGODB_URL
Works great with CI servers like StriderCD, too!

23. Larger MongoDB Fixture Data Sets
In our example, we wrote our fixture data using
the driver.
For larger data sets, you may want to use
binary dumps/restores. You can run the
`mongorestore` binary to load these.

24. MongoD Options for Faster CI
--nojournaling - You probably don’t need the
safety for CI.
--small - Use smaller default file sizes.
--noprealloc - Don’t pre-allocate files. Useful if
startup time with a fresh database is a
bottleneck.

25. Thanks!
Feel free to get in touch - we’re here to help!
niallo@frozenridge.co / http://frozenridge.co
@niallohiggins on Twitter
http://stridercd.com - Our Open Source CI
server written in Node.JS and MongoDB