Rules are made to be broken, right? TDD is a strict set of rules that define a process for building software. But experienced practitioners have moved beyond the rules and work towards something else entirely.

One of the first decisions you need to make when testing the rendered output of a component is which parts of it to test. The straightforward TDD answer is obviously all of it, but since we like to be lazy we look for excuses to not do that. Here’s how I decide what to test and what to not.

The surface area of a test is all the executed production code that happens within the “act” phase of a test. You can think of this as the code that the test covers, or the coverage of this single test.

If there’s one piece of advice that will help you write better unit tests, it’s this: always, always write your tests in Arrange-Act-Assert order.

Unit testing has fallen out of fashion within the front-end community. After half a century of structured programming, and twenty years of XP, our industry still struggles to benefit from unit testing. Why is this the case?