Let’s code, but first… TDD

Test-driven development, also known as TDD, is a software development process used to test software that will be written or before it is fully developed.

TDD will help with coding, reducing the number of problems during development. When we code, we must prioritize the software quality development process. This means we must follow the systematic strategy that focuses on all steps and artefacts produced to ensure the conformity of processes and products, preventing and eliminating defects.

TDD transforms development, as you must first write the tests before implementing the system. Tests are used to facilitate the understanding of the project, as they clarify the idea about what we expected from the code. For the application’s success, the test must be unitary and integrated. This means there will be tests that will test the components alone and others that are the built-in components.

RED

The first step is to write the test that expresses what you would like the code to do. At this moment we need to think about how the code is used and not how it works. At this point, the tests will fail as we don’t have the code yet, but that’s good. If you write a test and it passes, the test does likely not explore the scenario you want, or it will add little or no value.

GREEN

Next, we will write the minimum code necessary for the test to pass. The idea here is not to think of the perfect solution but the simplest one. Code improvements will be made in the next step of the cycle, so we want to get there as soon as possible. In real life, it’s easy to see that the minimal code will need to be changed in the next test, but it’s still essential to keep thinking about the simplest possible solution.

REFACTOR

Finally, let’s think about how to refactor the code since we have tests that guarantee that we won’t break anything. With each TDD cycle, we gain more understanding of the problem and safely adapt the code.

It is important to remember to refactor the code and the tests. In the code, we seek to avoid duplication to facilitate maintenance. In the tests, we desire to improve the readability so that people can better understand how our code works.

Do you want to do an example with me in Ruby?

The situation: Count the words of a text.

Let’s think about what we need to solve this problem. We need a method which takes a parameter (string) and this method will count the words.

Let’s call this method “count_words”. And the parameter “text”.

count_words(text)

First things first: TDD

If I don't have any text, I want to program to raise an error and output a message “There are no words to count”.

it "fails" do
   expect {count_words("")}.to raise_error "There are no words to     count"
end

Amazing! Now we can create a test with words to count.

it "Give a string with a text and return the quantity of words" do
  
  result = count_words("The quick brown fox jumps over the lazy dog")
  expect(result).to eq 9
end

This is the moment to try to run these two tests and…

RED!

This is because we didn’t add any code yet! Now it is time to write some basic code for the test to pass.

Let’s write a simple code which counts words.

def count_words(text)
  fails "There are no words to count" if text.empty?
  words = text.split(" ")
  return words.count
end

Let’s run and…

GREEN!

That’s great! But, wait…

What happens if we have a string with symbols or numbers? Our program should return only the quantity of words! And the words have only letters. Let’s refactor our test first.

it "Give a string with symbols and return the quantity of words" do
  
  result = count_words("I Love Ruby <3 !!!")
  expect(result).to eq 3
end

For our code, we need to keep only the letters.

def count_words(text)
  fail "There are no words to count" if text.empty?
  # Keep only capital and non-capital letters and blank spaces
  text.gsub!(/^A-Za-z] /, '')
  words = text.split(" ")
  return words.count
end

Great, we can repeat and continue creating more tests and refactor it!

Articles:

https://re-magazine.ireb.org/articles/learning-from-history-the-case-of-software-requirements-engineering/

https://web.archive.org/web/20160316153308/http://www.pathfindersolns.com/wp-content/uploads/2012/05/Effective-TDD-Executive-Summary.pdf