This article is part of our Testing from First Principles series. If you enjoyed this series, stay tuned for practical testing advice on my Cypress End-To-End Testing course on egghead.io

What is Code Confidence?

"Well, I do think there’s a good framework for thinking. It is physics. You know, the sort of first principles reasoning [...] boil things down to their fundamental truths and reason up from there, as opposed to reasoning by analogy.

Through most of our life, we get through life by reasoning by analogy, which essentially means copying what other people do with slight variations."

-Elon Musk

"You aren't paid to write tests, you just write enough to be confident."

-Kent Beck

We don't want to ship bugs to production. Break checkout. Lose our company a Monopoly sack stuffed with cash.

We want to be confident our code is safe to ship, but we don't always have an overflowing Monopoly sack on the line.

The value of confidence itself is based on what's at risk in your application. So before we consider how effectively tests can achieve confidence, I want to understand the value of confidence in the applications we write. Which begs the question...

What's At Stake?

What's the worst thing that could possibly break?

If you're changing the color of a button in checkout, your worst case scenario isn't that "the button is the wrong color." Your worst-case scenario is that you accidentally make the button display: none, and now there is no way to checkout. Goodbye Monopoly sack stuffed with cash.

So what do you work on? And what's your worst case scenario?

• A dashboard for day traders -> Crashing the stock market
• A blog -> No one can post all day :/
• A rocket to Mars -> The Challenger explosion
• A national defense project -> 9/11
• A sales report that helps your internal sales team -> The sales lead has to manually export his CSV today

This is what you're playing for. This is the sales pitch for your insurance policy. If you could be 100% confident this scenario would never happen, this would be the maximum benefit of confidence.

This is why you write tests, or gradually rollout your feature to users, because you want to avoid this worst case scenario.

There's also a second sales pitch for the insurance policy, maybe less talked about, but just as real, and that's how you'll feel emotionally after your worst case scenario happens.

• My boss will think I'm dumb
• I'll think I'm a fraud who should have never gotten this job
• My coworkers won't trust me anymore
• I'm pretty sure my parents will somehow find out about this

So let's add those two things together. Your worst case scenario is the combination of the two.

• No one could post blog posts all day, and my boss thinks I'm dumb, or
• I caused the Challenger explosion, and my parents found out

And that's the value of confidence, to you. Probably pretty important for your ego, the trust of your team, and possibly the world depending on what you work on. It is important to remember that there are cases where the worst case scenario is that the sales lead has to manually export his CSV today, and in those cases, I vote you stop right here, and say, "I'm not wasting valuable engineering time writing tests so that the sales lead doesn't end up clicking a button later today."

But only you know your worst case scenario. So now that you have it in hand, it's time to consider How To Play for Lower Stakes.

This article is part of our Testing from First Principles series. If you enjoyed this series, stay tuned for practical testing advice on my Cypress End-To-End Testing course on egghead.io