Why Write Tests?

• ...to validate your work
• ...to document expected behavior for others
• ...to more reliably enable large migrations or refactors
• ...to implement CI/CD

Why Not Write Tests?

• you are the only developer AND the project is small enough
• your business is evaporating
  • #1 most abused excuse
• you are utilizing a very strong statically typed language
  • not a great reason to avoid tests altogether, but can sometimes be good enough to omit certain types

Main Categories of Tests

• unit
• integration
• end-to-end (e2e) / system

Unit Tests

• most basic of all testing
• module or function
• most reliable way to ensure business logic works
• easiest to set up and (usually) fastest to run
  • however, arguably least useful out of the three depending on the size of your infrastructure

Integration Tests

• tests interfaces and boundaries between systems
• becomes much more useful as your infrastructure grows
• harder to set up because (if done right) you now have to spin up full services instead of just executing function calls or mocking out APIs
• more reliable way to ensure services can talk to one another

End-to-End Tests

• tests your entire infrastructure
• hardest to set up, but verifies all interactions throughout your ecosystem as it could exist in prod
• encompasses performance testing, visual testing, etc.
• most reliable way to enable continuous delivery

All Are Complementary

• No Silver Bullet
  • none can fully replace the others
• personal opinion: opt for integration or end-to-end over unit if you need to compromise

CI / CD

• Continuous Integration
• Continuous Delivery
• Continuous Deployment

Continuous Integration

• refers to frequency by which code gets "integrated" back into the main branch of your repository
• used to enforce automated testing and building as your project evolves
• conditionally executes different suites depending on context of commit
• tools
  • CircleCI, TravisCI, Jenkins, GitLab, TeamCity, etc.

Continuous Delivery

• refers to the process by which your entire release deployment is automated
• often utilizes infrastructure-as-code
  • Docker, CloudFormation, Terraform, Ansible, bash (hopefully not), etc.
• it is NOT concerned with validating that your application works necessarily

Continuous Deployment

• holy grail of software automation
• combines continuous integration and continuous delivery
• requires very high test coverage in your ecosystem
  • often combining all three test categories
• often enabled by feature flags
• canary deploys

... but why?

• using all of these processes give you a huge competitive advantage over organizations that don't
• pretty much a necessity for bigger businesses/infrastructures to scale
• again, No Silver Bullet
  • more stuff to maintain
  • can take a lot of time to set up depending on size of infrastructure

Jest

+

Other Facebook JS Projects

• React / React Native
• Flux / Redux
• Yarn
• ImmutableJS
• Flow
• GraphQL / graphql-js
• many others

Advantages

• all-in-one
• snapshot testing
• built-in mocking
• built-in code coverage
• caching
• codemods
• backed by Facebook

Disadvantages

• caching
• can't read config from other build tools
  • e.g., Webpack, Rollup, etc.