DEV Community

Debabrata Bhattacharya
Debabrata Bhattacharya

Posted on

Why Testing?

What is testing? What does basic testing look like? Why should we test our code?

So THIS is testing!?!?

Every beginner, newbie code, and self-taught developer has heard of testing at least once. You might have read and written code to implement testing. But you might feel like you didn't really get it. So let's talk about it briefly.

How do we know if what we see is real?

It might sound like a silly question, but it is a profound one at the heart of testing. When we write something with a pen, we can see the ink staining the paper. We can feel the wind pass us by, and we can smell the smoke when something burns. But computers do none of these things, except under unfortunate circumstances.

When we build software, we want it to work. So we manually go through the app, reading the outputs on our screen to see if they are ok. However, this takes time and is prone to error. Thankfully, doing repetitive tasks with reliability is something computers are very good at.

And that is why we write tests!

A test is a function, class, or statement that interacts with another piece of code—to check if the other piece is working correctly. Without tests, it can get pretty hard to know what is working, what isn't, and what needs to be done.

Why test driven development(or TDD)?

Test driven development is exactly as it sounds like! We design the entire development workflow around testing our work automatic tests. It follows a Design -> Write test that fails -> Write code until test passes. Then we work on the design, write a test for the new design, and write code until the new test passes. We keep iterating like this, until we have all the functionality we need out of our code base.

It is known as the Red -> Green -> Refactor cycle

The testing cycle is made of three parts: Creating or refactoring a design, Writing a test for the design that fails, Writing code until the test passes.

What happens if we don't do testing from the start?

Imagine a robot that cleans the floor. It sees the floor as a set of squares it can move in. It's job is to sweep the floor one square at a time.

There is a robot on a set of 6 squares in a 2 x 3 formation of 6 squares. 5 of the squares are grey, indicating they are dirty. One of the squares is white, indicating it is clean. Below that is the same set of squares, 4 are grey, 2 are white. Indicating that one has been cleaned.

Now, imagine that after the robot has cleaned everything, one of the squares is found to be dirty! The robot has to go and clean it all again.

There is a robot beside a set of 6 squares in a 2 x 3 formation of 6 squares. 5 of the squares are white, indicating they are clean. One of the squares is grey, indicating it is dirty.

To clean the squares, the robot has to traverse all over again. And in the process of cleaning, another becomes dirty! The robot grows angry, frustrated at working for the whims of a non-sensical world.

There is a robot on a set of 6 squares in a 2 x 3 formation of 6 squares. 5 of the squares are white, indicating they are clean. One of the squares is grey, indicating it is dirty. A different square than previous is dirty

Now imagine that the robot, after cleaning each square, checks that the cleaning has been done properly, and no other squares have become dirty in the process. The end result is a clean floor. And a happy robot!

There is a robot beside a set of 6 squares in a 2 x 3 formation of 6 squares. 6 of the squares are white, indicating they are clean.

THAT is TDD! By testing our code every time we change it, we ensure that we arrive at our destination much quicker! And happier too!

So we test because

  • Velocity is higher than not.
  • We ensure quality.
  • It is easier and faster to check quality.
  • Developers, testers, designers, product managers, and other stakeholders are happier!

Meta

Attributions

Version

  • Article version: 0.0.0.1
    • No edits.

Top comments (0)