- why?
- how?
- what? comes from experience and the system we're testing and even the tech stack.
- when? test-first vs test after.
- good for resume.
- can work on QA and DevOps.
- helps understand how an application works.
- Verifying correctness.
- Confidence (in the sense of trusting your code).
- Safety net.
- Prevents regressions.
- What could happen if I have no tests.
- test manually, as the app grows, the time needed will not scale.
- regressions, code that used to work breaks.
- you just don't know if the code is correct for all cases, including edge/corner cases.
- adding new features becomes slow.
- angry customers => product fail.
- We write code to test our code.
- Tooling: Test runner (Mocha, Jasmine, Jest, QUnit) + assertion library (Chai, Assert, Jest, Jasmine).
- We are using Jest for everything.
- unit tests. Fastest.
- integration tests. why it is important. Other Examples
- end to end. Slow.
- component testing. (for component based frameworks, like React, Angular, Vue, etc.)
- snapshot testing. (unique to our stack/tools)
- coverage testing.
- functional testing.
- performance testing.
- aceptance testing.
- fast.
- simple to write and execute.
- used to test correctness.
- written by developers.
- the tool for doing TDD/BDD.
- appearance and functionality of a component.
- highly sensitive to small changes.
- great against regression.
- verifies changes to component output resulting from changest to state.
- does not verify interaction between components.
- automatically generated by Jest.
- sub-type of component testing.
- checks current output against prior output.
- fails with any change to the component.
- very good to detect regressions.
- unit.
- component.
- snapshot.
- integration.
- a test runner + cli in npm package.
- made by Facebook and included out of the box with create-react-app.
- general purpose, but works very well with React applications.
- recommended by the React team.
- can:
- run tests (mocha too)
- asynchronous code testing (mocha too).
- spies included.
- snapshot testing.
- module mocking.
- includes coverage reports
- installed globally.
- installed locally.
- if NOT used with a CI (Continous Integration) server, install it as a devDependency.
- configure npm scripts.
- on development run it in watch mode.
- any file inside a
__tests__
folder will be run automatically. - any file that ends in
.spec.js
or.test.js
will also be executed automatically.
- easy to find.
- unrelated files together.
- easy to isolate a particular set of tests.
- files can be named anything.
- always adjacent to the files the apply to.
- unrelated files are less likely to share a folder.
- need to follow the naming convention.
- the
it
global is a method you pass a function to, that function is executed as a block of tests by the test runner. - the
describe
is optional for grouping a number of relatedit
statements. This is also known as asuite
.
- instead of running the tests manually use watch mode.
- tests run automatically as files change.
- only tests pertaining to changed files run.
- Jest detects changes automatically.
- change the npm test script to:
jest --watch
. - changing the code or the tests will re-run the tests.
- using
ctrl + c
will stop the test runner/watcher.
Some commonly used (and useful) matchers.
toBe
: that two values are equivalent using strict equality (checks reference/identity).toEqual
: that two values are equivalent by looking at the values (if walks like a duck, it's a duck). For two different arrays with the same values, toBe fails and toEqual succeeds.toContain
: checks that a value exists in an array.toHaveLength
: checks the lenght of an array. Like toContain, it is more readable than using toEqual and toBe combined with array methods.not
: reverses the assertion.
- can we install Jest globally?
- can Jest tests be run as part of the build and deployment processes?
- why is
watch mode
convenient? how can we "turn it on" when running our tests?
- fast.
- simple to write and execute.
- used to test correctness.
- written by developers.
- the tool for doing TDD/BDD.
- drawbacks of testing.
- more about Jest.
- setup and teardown globals.
- skipping and isolating tests.
- testing asynchronous operations.
- more code to write, and maintain.
- more tooling.
- additional dependencies.
- may provide a false sense of security.
- trivial test failures may break the build.
- a test runner + cli in npm package.
- made by Facebook and included out of the box with create-react-app.
- general purpose, but works very well with React applications.
- recommended by the React team.
- can:
- run tests (mocha too)
- asynchronous code testing (mocha too).
- spies included.
- snapshot testing.
- module mocking.
- includes coverage reports
- exist in the global scope like
describe
andit
. - beforeAll: runs once before the first test.
- beforeEach: runs before the tests, good for setup code. // test runs
- afterEach: runs after the tests, good for clean up.
- afterAll: runs once after the last test.
- setup and tear down vs
factory pattern
.
- skipping tests:
it.skip()
- isolating is used to pick the tests you want to run:
it.only()
- it also works at the test suite level:
describe.only()
ordescribe.skip()
- does not complete right away.
- Jest must be notified that the test completed.
- techiques:
- invoke a
done()
callback that is passed to the test. - return a promise from a test.
- pass an
async
function toit
. Not supported everywhere yet.
- invoke a