System Testing an API with NodeJS and Mocha

Do you test as much as you think you should? Or, even if you write tests, are you still confused about the different types of tests, how to structure and name your tests, or even what to test in the first place?

In this talk, Daniel Bostwick will walk through how he structures a NodeJS project for testing, integrates the Mocha and Chai testing frameworks, discuss the guidelines he uses for figuring out what to test, and show an examples of how to functionally test a backend API. You'll come away with a better understanding of BDD, learn how to functionally test any api, and be inspired to better test your own APIs.

Transcript

1. System Testing an API
 with NodeJS and Mocha 1
2. 2 Daniel Bostwick cantina.co
 danielbostwick.com
 
 github.com/bostwick
 linkedin.com/in/dbostwick Senior Technical Consultant
3. 3 Testing Philosophy
4. 4 Testing Misconceptions What testing is not
5. 5 You Need To Test
6. 6 You Need To Test Testing is not a requirement for a successful* project. *depending on your definition of success.
7. 7 You need 100% test coverage
8. 8 You need 100% test coverage 100% Coverage is a great ideal, but any coverage will help improve a project.
9. 9 Testing proves your program is correct or free of bugs
10. 10 Testing proves your program is correct or free of bugs Unless you’re using formal verification systems, testing can prove nothing.
11. 11 Writing tests means you can “grow” your architecture over time, instead of up front
12. 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
13. 13 So, Why Write Tests?
14. If you aren’t testing, your users are. 14 Because it’s inevitable.
15. - Ronald Reagan 15 Trust, but verify.
16. 16 Testing demonstrates the behavior of software.
17. 17 A test ensures that a system behavior remains constant even as the underlying implementation may change.
18. “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
19. 19 What should be tested?
20. 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”));
 }
21. 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 .
22. 22 Behavior The way in which a system acts in response to a particular situation or input.
23. 23 Job Story When ______________ , I want to _______________ , so I can _______________ .
24. 24 Behavior is independent of implementation. # This passes, too!
 “use strict”
 console.log(“Hello, World”);
25. 25 Test Categories Unit Tests Integration Tests System Tests
26. 26 How to Test?
27. jsUnit, jUnit, OCUnit, Test::Unit, PyUnit 27 xUnit You already have it.
28. 28 Naming Tests How it’s taught. “use strict”
 
 module.exports = {
 sayHello: function(name) {
 return “Hello, “ + name;
 }
 }; “use strict”
 
 var myLib = require(“hello-lib”);
 
 function testSayHello() {
 assert(myLib.sayHello(“World”) ===
 “Hello, World”);
 }
29. 29 Job Story When ______________ , I want to _______________ , so I can _______________ .
30. 30 Behavior-Based Test Names function
 testSayHello_givenName_returnsHelloName function testSayHello_givenUndefined_returnsNonsense function testSayHello_givenObject_returnsHelloObjectObject http://dannorth.net/introducing-bdd/
31. 31 Spec-Based Testing define(“sayHello”, function() { 
 define(“given a name”, function() {
 it(“returns ‘Hello, {Name}’”, …); }); 
 define(“given a number”, function() {
 it(“returns ‘Hello, {Number}’”, …); }); });
32. 32 Your test names should be executable documentation.
33. 33 Writing System Tests for an API
34. 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.
35. 35 Tools 1. NodeJS 2. Mocha & Chai
 http://mochajs.org/, http://chaijs.com/ 3. request
 https://github.com/request/request
 4. Bluebird Promises
 https://github.com/petkaantonov/bluebird
36. 36 Project Structure project-name/ [bin]/ [config]/ src/ or lib/ project-name/ test/
 project-name/ helpers.js
 Readme.md package.json
37. 37 Installation $ npm install —save-dev mocha chai bluebird request
38. 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
39. 39 Testing the Climb Higher API
40. 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
41. 41 System Test Setup & Teardown https://github.com/climbhigher/climbhigher-api/blob/master/test/climb- higher/routes.js#L14
42. 42 Simple Endpoint Test https://github.com/climbhigher/climbhigher-api/blob/master/test/climb- higher/routes/get-user.js
43. 43 Complicated Endpoint Test https://github.com/climbhigher/climbhigher-api/blob/master/test/climb- higher/routes/post-session-ticks.js
44. 44 Extract Common Helpers https://github.com/climbhigher/climbhigher-api/blob/master/test/ helpers.js
45. 45 What about unit tests?
46. 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.
47. 47 Thank You Questions Welcome