Are you testing too much, or are you just writing too much code? 🤔

Over the past few years of coding, I’ve fluctuated between not testing at all to testing too much. In part, it’s because the principles behind testing are not exactly something that’s taught in a formal setting. Nor is there some sort of consensus on how it’s done.

Everyone has their own opinions when it comes to testing. Testing methodologies can also vary, depending on the scope and final purpose.

When it comes to testing your code, too many tests can slow down your progress and gridlock you into test units. Not enough testing can lead to flaky code.

So what’s the right amount? And how do you go about implementing it? Rather than going into the usual talks about test-driven design and all that stuff, let’s take a different approach towards testing your code.

Finding the Balance in Testing Your Code

  1. Start with the end in mind
  2. Your application in a nutshell
  3. Are you testing too much?
  4. How do you know if you’re writing too much code?
  5. Final Thoughts

Start With The End In Mind

A lot of developers tend to just start coding. When it comes to following tutorials or coding up your own projects, many of us use a play it by ear kind of approach.

While there is nothing wrong with this, for larger and complex applications and systems, this can be a design process flaw. The thing with writing test units is that you have to understand how things are going to end up.

The act of writing the code becomes a process of coloring in the pieces with logical indicators, data processing, and information transformation. This is why you need to know what your end goal is. Without it, your test’s value runs on a system of diminishing returns.

So how do you determine what your end goal looks? What happens when you’re working in an agile environmentwhere things are constantly changing?

You start with the big picture…

For the rest of this post, please check it out at