Webinar: Continuous Integration with Node.JS and MongoDB


Published on

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.

Published in: Technology

Webinar: Continuous Integration with Node.JS and MongoDB

  1. 1. CI with Node.JS and MongoDB © Niall O’Higgins niallo@frozenridge.co https://github.com/FrozenRidge/node-mongodb-ci-webinar
  2. 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. 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. 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. 5. Testing in Node.JS What is a test suite? A test suite consists of: ● Test Runner ● Assertion Library ● Tests
  6. 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. 7. Node Test Runners Some Popular Node.JS Test Runners: ● Mocha ● Nodeunit ● Node-Tap ● Vows
  8. 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. 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. 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. 11. Assertion Style: TDD vs BDD BDD: expect(myArray).to.have.length(3) TDD: assert.equal(myArray.length, 3)
  12. 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. 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. 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. 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. 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. 17. Create Node.JS Project w/Tests 1. Run tests 2. They fail! 3. No implementation
  18. 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. 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. 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. 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. 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. 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. 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. 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