Do We Even Need Testing?

4 min readMar 21, 2021

Test-Driven Development (TDD)! Some people want it, some people loathe it, but the fact is that it exists, and we may need to implement it for our PPL course. Fun, right?

A Quick Look

For starters, what is TDD? TDD is a practice in software development where developers create a test first before implementing anything (RED), then write the code needed to pass said test (GREEN), then rewrite the code if needed (REFACTOR).

Just like every thing in this world, there are advantages and disadvantages to this practice, so let’s start with the good first.

Advantages

Better functions — With you writing the tests first, this means that you have an idea of what your function wants to do, what it’s supposed to do. You would want to write a code that fulfills a certain test, and when it passed, you can either move on to writing other tests or refactor that code. This means that most function can be guaranteed to only do one purpose.

No cases left unchecked — With TDD, you would want to write tests that covers any possible situations. This means that errors are very unlikely, or won’t happen at all (unless there are some cases that the developers missed).

In short, TDD can improve the code quality of a project.

Disadvantages

Unnecessary — This can happen when you are aiming for 100% code coverage. People can be so focused with the 100% number, that they can start to write tests for the sole purpose of getting that sweet 100, rather than writing tests to sustain or improve the quality of a project.

Longer codes, longer development time — Sometimes, the tests you make can be passed with only a short amount of code. Now imagine writing that kind of test over and over again, and you can get yourself a large amount of lines, only for testing. Not only that, there’s a possibility that you spend way too long to come up with tests, rather than actually working on the implementation.

So what do we do?

Is TDD good? I would say yes. Is TDD really important? Personally, no. Does it help? It could, yeah.

Here’s the thing, it’s wrong to think that TDD is not a must-implement thing that every project needs. It is also wrong to think that TDD only serves as a speed bump for your project development.

Think of a tool you regularly use. Think of its usage, then think of possible misuse of that tool. The same can be applied to TDD. TDD is just a tool, and a tool is only as useful as its master (I may have gotten that saying wrong). No matter how good a tool is, if its user can’t get the full potential of it to be working, there’s an argument that that tool may not be needed in the first place.

One of the biggest stumbling block I can think of is, “What exactly is a quality unit test?” “Why should we write tests that we know the answer of?”

I know this URL will have something eventually, is it really important to test it?

I think that comes down to my lack of knowledge of testing. Most of the time I am too focused on code coverage that I forgot to think whether the test is good in the first place. Besides, even though sometimes a test may look like unnecessary, it’s good to have every possible case documented and tested, no matter how big or small the case is.

In a team environment, I believe TDD is greatly beneficial. It reassures us that our project is bug-free for the most part, and the bulk of writing tests can be shared between members. More people also mean that more variety of tests can be written as a member can come up with tests that others might not have thought.