webinar: continuous integration with node.js and mongodb
DESCRIPTION
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.TRANSCRIPT
CI with Node.JS and MongoDB© Niall O’Higgins [email protected]://github.com/FrozenRidge/node-mongodb-ci-webinar
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
Create Node.JS Project w/ Tests
Live coding!
1. `npm init` in empty directory2. Hit return on prompts3. Run `npm test`4. What happens?
Testing in Node.JS
Our empty new project’s test suite failsLet’s write a test suite!
But first we should talk a little about writing tests in Node.JS
Testing in Node.JS
What is a test suite? A test suite consists of:
● Test Runner● Assertion Library● Tests
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 off-
the-shelf
Node Test Runners
Some Popular Node.JS Test Runners:● Mocha● Nodeunit● Node-Tap● Vows
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.
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
Assertion Styles: TDD vs BDD
Mostly matter of emphasis and preferenceBDD = more “English-like” assertionsexpect(myVar).to.equal(“hello”)
TDD = more “code-like” assertionsassert.equal(myVar, “hello”)
Assertion Style: TDD vs BDD
BDD:expect(myArray).to.have.length(3)
TDD:assert.equal(myArray.length, 3)
Assertion Style: TDD vs BDD
We use ChaiJS as our Assertion Module as it:
● supports both TDD and BDD styles. ● has many convenient assertions.
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`)
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!
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.
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
})
})
Create Node.JS Project w/Tests
1. Run tests2. They fail!3. No implementation
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!
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 ]
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 whichtalks to MongoDB.
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.
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!
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.
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.
Thanks!
Feel free to get in touch - we’re here to help!
[email protected] / http://frozenridge.co@niallohiggins on Twitter
http://stridercd.com - Our Open Source CI server written in Node.JS and MongoDB