Why Testing Matters

Tests exist so you can change code without checking everything by hand.

That is the justification, and holding onto it is useful, because it gives you a way to judge any individual test: does this one make me more willing to change the code? Tests written for other reasons — to hit a coverage number, to satisfy a rule — tend to be the ones that get deleted.

Imagine a pricing calculation used in eleven places. You need to change how discounts combine. Without tests, you make the change and then face a choice: manually exercise eleven scenarios, or hope.

In practice, people hope. Or, more often, they avoid the change altogether and add a special case alongside the old logic. Do that a few times and you have code nobody wants to touch — not because it is complicated, but because nobody can predict what a change will break.

[Fact]
public void ApplyDiscount_WithTenPercent_ReducesPriceCorrectly()
{
    // Arrange
    var calculator = new PriceCalculator();

    // Act
    decimal result = calculator.ApplyDiscount(200m, 10);

    // Assert
    Assert.Equal(180m, result);
}

• The name states the scenario and the expected outcome, so a failure is informative before you read any code.
• Arrange, act, assert: set up the situation, perform one action, check one outcome.
• This test now runs in milliseconds, every time anyone builds, forever.

The shape matters more than the labels. Many small fast tests catch logic mistakes immediately. A smaller number of integration tests catch wiring mistakes that unit tests structurally cannot see. A handful of end-to-end tests confirm the critical paths work as a whole.

Inverting this — mostly slow end-to-end tests — produces a suite that takes twenty minutes, fails intermittently, and gets ignored. At that point it costs more than it returns.