[Zero Two]

Testing advice tends to swing between "test everything" (impractical) and "testing is a waste of time" (wrong). Here's a more nuanced take after years of both writing and maintaining test suites.

What to definitely test:

• Business logic - the rules that define what your application does. If a bug here reaches production it causes real damage. Pure functions with clear inputs/outputs are the easiest to test well.
  
• Edge cases that have caused bugs before - once you've fixed a bug, write a test that would have caught it. This is the highest-ROI testing you can do.
  
• Integration points - API contracts with external services, database queries, anything that crosses a system boundary. Mock at the boundary, not inside your code.
  
• Anything you're not sure about - if you had to think about whether the code was correct while writing it, test it.
  

What's often not worth testing:

• Trivial getters/setters and pass-through code
  
• Framework internals - trust that Express routes work, that ORM queries produce correct SQL
  
• Things that are constantly changing - tests that need updating every time you tweak a UI component create more friction than they prevent
  
• Implementation details - test what code does, not how it does it. Tests coupled to implementation break on every refactor.
  

Test pyramid in practice: lots of fast unit tests on business logic, fewer integration tests at the service boundary, a handful of end-to-end tests for critical paths. Not the other way around.

The best metric: does the test suite give you confidence to refactor and ship? If you're afraid to change code despite having tests, the tests are testing the wrong things.