mocha sinon chai Dc jquery 4-24


Published on

High level overview of some testing tools and how they can be used together.

Published in: Software, Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

mocha sinon chai Dc jquery 4-24

  1. 1. Carson Banov Testing and Tools
  2. 2. Testing and Tools Mocha, Sinon, Chai
  3. 3. Why is testing important?
  4. 4. Unit testing: tests the smallest piece of code that can be tested. These units are the building blocks of a piece of software. Ex: A function works correctly, a class has some method and data, etc. Unit tests are a basic guarantee that the code you have written is doing what you want it to. "I know this code will always spit out X if it is passed Y." If you are developing as a team, it proves to the other coders that your code is doing what you want it to. "This function is coded correctly and I can prove it since these tests pass". Allows you to build multiple 'units' together which helps in debugging. "I know that this part of the code does this every time, so the problem is not there." unit testing
  5. 5. Functional testing tests a slice of functionality of the application. A functional test guarantees a feature works. Ex: A feature works correctly, some action triggers an appropriate response, can touch multiple layers of an application. Allows you to test that a series of units are working together correctly. "The add new user feature works correctly." Allows you to know when you have broken something important. "This test broke, so my changes have changed how this works." Allows you to map code to features. "The sign-up form is done, because we have tests that cover a user's actions upon signing up." Allows you to know that layers of an application are working or interacting correctly. "I know the server is successfully talking to the database because this test passes." functional testing
  6. 6. Up to you.* Before: write them as a planning exercise, and you know when your feature/branch is done. During: to figure out why it is not working, to track down bugs. After: to test edge cases, provide proof your branch is working, and to ensure future changes don't break this functionality. * As long as your boss doesn’t tell you differently and you do actually write them at some point. when to write tests..
  7. 7. getting started $ npm install mocha $ npm install chai $ npm install sinon Can be used to test front-end javascript as well as a server-side node application.
  8. 8. mocha “Mocha allows you to use any assertion library you want, if it throws an error, it will work!” This is where Chai comes in.
  9. 9. Essentially gives "expect", "should", and “assert”. Expect and should keywords can be chained in ways that are quite readable. var foo = 'bar''string'); foo.should.have.length(3); expect(foo)'string'); expect(foo).to.have.length(3); assert.isString(foo, 'foo is a string'); Chai
  10. 10. back to mocha A test suite is organized with series of functions using the keyword "describe". An individual test is a function specified using the keyword "it".
  11. 11. more practically Describe blocks should be well named. We use “should …” convention to signify a test.
  12. 12. output . . . . . .
  13. 13. uh oh
  14. 14. async Just add ‘done’.
  15. 15. test setup, independence before(), after(), beforeEach(), afterEach() Make sure tests are independent. You can and should run each one on its own and they would pass.
  16. 16. reusing data Use describe blocks and setup hooks to create desired data.
  17. 17. .skip and .only Can be applied to individual tests or describe blocks. Skip can be used while writing a test or series of tests to unclutter the output or skip a test that is failing because you haven’t gotten to that yet. Less recommended: while first starting a code base you can use skip as a placeholder for tests that you need to write but the application doesn’t have those parts implemented yet. Only is great for repeatedly running just 1 test while working on getting it to pass. Used for local testing (don’t want any .only flags in actual source).
  18. 18. .skip and .only Be careful of letting these flags get into source.
  19. 19. using Sinon For testing only what you mean to test. Provides methods for checking information about function calls and spoofing what those function calls return.
  20. 20. Spies: used to ‘wiretap’ a function. For ensuring a function is being invoked with the right argument(s) at the right time(s). From Sinon: "original function will behave just as normal." spies
  21. 21. Stubs: used to replace a function with a custom version. Same power of inspection of a spy, but changes the behavior of the function. From Sinon: "the original function is not called". Helps isolate a part of code to be tested. Can specify different return value than the actual function (test error handling, avoid making unwanted network requests), even fine tune this down to what it should return on successive calls to the same function. stubs
  22. 22. You can use the before, beforeEach, after, afterEach hooks to persist and reset the Sinon features. synergy with mocha
  23. 23. Sinon has a built in feature for helping you keep track of stubs, etc that you create: the sandbox. synergy with mocha, Sinon sandbox
  24. 24. The sandbox can be used in beforeEach and afterEach as well as nested. synergy with mocha, Sinon sandbox
  25. 25. ‘Fixtures’ are often used to be imported as fake data that can be returned or accessed by stubbed methods. Can even be used to store fake functions to use as those stubs. You can use these on/with travis-ci, jenkins Easy to configure a basic html page that runs the tests as well as make a grunt command to run them. extra stuff
  26. 26. links
  27. 27. thanks Questions?