I recently started hosting AMA-style cafe chats with developers at various stages of their journey, about software engineering and anything else within my technical experience. Below are some rough & rapid-fire notes from the chat on Oct 21st, 2022.

“Why test?”

Tricky question because it puts you in the mindset of writing test code after application code (rarely you’d think IRL of testing something that’s not there).

• Better question: Why write down your goal before starting to work on it?
• TDD used to be called “Test-First Design”; good but not great (the word test is still there); attempts at rebranding as “Behaviour-Driven Development” sadly failed.
• Ideally someone with a magic want would replace test(description, tester) with rule(definition, validator) everywhere.

“If you look at two typical hours of your coding, what’s taking most of that time?”

For me, checking that a change I made does what I want, and checking that a change that I made doesn’t break something else. In other words: validation.

• Not just a time cost — the frequent context switch has high attentional cost.
• Automating validation shifts a large chunk of the time cost to the machine. Well written tests (running in <5s) also save the attentional cost.

“My application is still simple. Maybe I can postpone writing tests for a while longer still?”

• Has it happened yet that something that was working before suddenly stopped working and you don’t know why? If so, guess what that means.
• Any form of automated validation shrinks the time between defect introduction and defect detection/correction. If you imagine your codebase’s evolution as an arrow growing with time, automated validation helps increase the work you do near the pointy end of the line instead of repeatedly jumping back on the line to fix things that used to work.

Critical thinking not optional

• Test all the things, then? Not so fast. A situation might not just call for automated validation (e.g. exploring a problem space) or not call for it yet (e.g. integrating with pieces you have no control over that will drastically influence the choice of a testing strategy).
• Even when automated validation is called for, example-based tests aren’t necessarily the best form; sometimes you may want snapshot-based tests (whether at the data or the visual level) or even property-based tests.