- Small tests should force code to be more modular
- Helps you learn and understand the key components of modular design
- Better architecture by-proxy; by making sure all our code is unit testable we
- Have to have proper modularization as above
- Are more likely to surface architectural issues earlier
- Code is easier to maintain, refactor and even rewrite because we have a baseline of what a module should do and what we view as acceptable/unacceptable behaviour for it.
- Actual self documenting code that doesn't go out of date because it's always running and being updated
- Easier to pick up someone elses code without a big handover. Having tested code means we should be confident changing and adapting unfamiliar codes because we have existing tests that let us know if it's working or not
- Writing tests first should help us write only the simplest solution rather than searching for potential edgecases and gotchas before they surface
- Allows us to ship code at any time because our code is well tested and well engineered by following the principle of (simplest) Red -> (simplest) Green -> Refactor
- Easier to refactor legacy code that has tests as we should know if something breaks. This allows us to move faster and with more confidence.
- Helps both existing and new engineers to understand what's actually happening in
code
- Makes it easier to conduct Code Reviews, if the code has tests I'm more likely to know what it does and how it does it, that it works and that it hasn't caused an unexpected defect for other modules.
- It helps to clarify requirements because you have to figure out concretely what inputs you have to feed and what outputs you expect.
- "Lapses in concentration" should be discovered pretty much immediately rather than having to hotfix them afterwards
- Less likely to break things = happier customers = Prouder Engineers
- Higher quality code while delighting all of our customers
- Slow to get started
- If you've not being doing TDD it can be slow to get (back) into the habit of writing tests and doing the correct cycle
- Can be hard outside of unit testing level
- Hard to apply to legacy code
- But something we should do anyway
- You sometimes have to mock a lot of things or things that are difficult to mock. It’s beneficial in the long term, but painful right now.
- If we're not careful and over engineer our tests we'll end up with long builds
- https://qualitycoding.org/slow-tests/ (ignore the Xcode focus)
- Early stage refactoring involves refactoring the test class
- Requires everyone to buy-in to maintain quality of test suite