TDD - Create tests that make sense

Do you know TDD? I mean, do you REALLY know TDD?

I'm asking because even though this is a common acronym in today's tech vocabulary, it's still common to find people testing blindly(or even, not testing at all).

TDD is not a new technique, but today it is a must-have skill in development. For example, many jobs descriptions require this competency. So, if you want to understand TDD, this is the perfect article for you.

How TDD works

TDD is the acronym for Test-Driven Development. That means that you will write your code based on your tests.

Your tests come first.

This way, you can focus on how your code has to work and, most importantly, how it shouldn't work. So doing the tests first helps you think about all the possibilities and avoid overengineering while coding.

Does this seem an impossible task? YES. Will your mind blow? Also yes. But trust this will help you write a more resilient code.

How to write a good test

Ask the right questions. And use the AAA technique.

1. What are the basic properties?
2. What are the main methods?
3. What should you avoid at all costs?

• Arrange: Initialize objects and declare variables.
• Act: Call the tested methods using the params created in the first step.
• Assert: Check the results. Compare if the results are equal to the expected values.

With these three questions and the AAA structure, you can improve the quality of your test.

Practical examples

Now you can drive into some code. You're gonna be creating a basic door with some basic tests. The functional requirements are:

• The door has a color. But the color shouldn't be red.
• The door has height and width. But the height has to be 3x the size of the width.

Pay attention

Do not worry about how to code the Door class, the main method and things like that. First, you think about your tests, and while you write the test you will find out what you will need to code after.

Asking the right questions

What are the basic properties?

The door has a height, width and color. So, when creating a door you need to validate if those 3 properties are present. Now you've got your first test case:

test("Should create a door with height, width and color", ()=>{
  //arrange
  const door = new Door()

  //act
  door.create(12,4,"black")

  //assert
  expect(door).toHaveProperty("height",12)
  expect(door).toHaveProperty("width",4)
  expect(door).toHaveProperty("color","black")
})

What are the main methods?

The create is your principal method.

What should you avoid at all costs?

At first, two situations shouldn't happen. Let's start there.

The door should not be red. And the height has to be 3x the width.

test("Should throw if the door's color is red", () => {
  const door = new Door()
  const doorRed = () => door.create(12, 4, "red")
  expect(doorRed).toThrow()
})

test("Should throw if the height is not 3x the width size", () => {
  const door = new Door()
  const wrongDoorHeight = () => door.create(10, 4, "black")
  expect(wrongDoorHeight).toThrow()
})

Now that you've got all your test cases, it's time to code it. Consider that in the tests you needed:

1. A Door class
2. Three properties
3. A create method that receives three params

So your class should be someting like:

Conclusion

Awsome! Now that you already know how to structure your tests. You may explore other cases to practice. Those are just some of the basic tests you can do with TDD. Also, what about starting practicing on your day to day basis?

Therefore, this is the first article about testing from the series TDD for everyone.

I hope you have enjoyed it! ✨

Comments

[Oliver Brown]

excellent article