Spice it up with TDD

Music Intro

Intro

Let’s dive into the world of Test Driven Development (TDD) together, shall we? 🚀

So, what exactly is TDD? Well, it’s a way to describe things in a programming language.. Imagine it’s like telling a story, but instead of using words, we’re using code!

Here’s how it works: when we want to describe something using English, we focus on describing one thing at a time.

Sometimes we have to go back and fix things up, when we find out that they are not right. It’s like building with Lego bricks – we start with one piece and add more as we go along!

But here’s the cool part: just like in science, where we use peer-review to see if other scientist agree with our observations!

And just like in physics, we can even test our code to see if it behaves the way we expect it to. It’s all about making sure our code is usable and understandable, just like a science experiment!

So, think of TDD as our own little computer-science experiment. We write down our descriptions and then make sure the computer behaves the way we want it to.

It’s like conducting our very own coding experiments and seeing what happens! 🤖✨

Lets do some coding!

Remember to use: 💻 Python / 💻 JavaScript / 💻 Groovy / 💻 C#

Lets start printing the output, so we manually can assert it:

# Given
number1 = 1
number2 = 2

# When 
result = number1 + number2

# Then
print(result)

and verify it manually:

What we can do instead, is to assert it automatically, by replacing print with assert:

# Given
number1 = 1
number2 = 2

# When 
result = number1 + number2

# Then
assert(result == 3)

The == means that we want the computer to verify if the equal is actually equal.
It responds with either true (the equal is equal) or false (the equal is not equal).
The assert consumes the true or false and if it’s true, then it does nothing, because everything is fine:

If it’s false, then it fails with an AssertionError and prints the result.
To see that, we need to replace the 3 out with a 4 (because 1+2 is not 4):

# Given
number1 = 1
number2 = 2

# When 
result = number1 + number2

# Then
assert(result == 4)

Then we will see an assertion error, where the result is not 4:

To give it a better error message, we could add an actual error message:

# Given
number1 = 1
number2 = 2

# When 
result = number1 + number2

# Then
assert(result == 4), f"{result} != 4"

Which gives:

The f in the f”…” means it is a text with parameters, where we can take the value of result and put it inside the text. So, f”{result} =! 4″ becomes: “3 != 4”

The f”…” exist in each of the 4 programming languages and has it’s own name:

You can see, some languages are more fun than others 😂

Why use an assert, when print makes it much easier?

In a simple program like that, we can use a print.

A more complex program may have 20 kinds of outputs, depending on the inputs.
It is much easier, faster and more precise to automate all the outputs, instead of testing them manually:

# Imagine we have already a complex program called buyTicket(numberOfZones, travelerType)

# here would the tests be:
assert (buyTicket(1, "adult")=="2 €")
assert (buyTicket(8, "adult")=="16 €")
assert (buyTicket(1, "child")=="1 €")
assert (buyTicket(8, "child")=="8 €")
# etc... 

No need to run the buyTicket manually 20 times and checking all the values are correct.
A machine can run a 1000 test cases per minute, and we humans can’t.
And there is also no need to remember all the results, when the machine can do it for us.

Testing before coding

TDD is not only about testing the code.
TDD is actually about writing the test before the code, which in principle means:

The given and then code is written first:

# Given
number1 = 1
number2 = 2
number3 = 3
number4 = 5

# When 
# your code goes here

# Then
assert(result1 == 3), f"{result} =! 3"
assert(result2 == 4), f"{result} =! 4"
assert(result3 == 5), f"{result} =! 5"
assert(result4 == 6), f"{result} =! 6"
assert(result5 == 7), f"{result} =! 7"
assert(result6 == 8), f"{result} =! 8"

The when code is written last, for technically the given and then are the specification of the wanted system behavior. The when code needs to fulfill it.

And whenever we want to change the specification, we just need to change the given and the then code. Then we will see the existing when code needs also to be updated to the new specification.

Excercise: Write the needed when code, to make it pass. Please don’t change the code in the given and then.

What to do

In the next lessons, we will do some coding exercises.

I would like you to use the assert, so you don’t have to remember the results from all the exercises.

You are welcome to add a print, if you want to. It can be very useful, to use a print, get a view inside to see what the code is doing.

Saving and loading

In the web editor, there is no option to save your code, but what you can do is to copy & paste your code into a notepad for future use.

Then you can always copy & paste it back into a web editor, if you want to use it again.
It is also possible to have multiple web editors open, without them interfering with each other.

Last exercise for this lesson:

Add an assert after the print. And make sure the whole code passes.

# Given name and a greeting is defined (you can use any name)
name = "Bartek"
greeting = "Hello"

#When the greeting, a space, and the name is combined into the text.
text = greeting + " " + name

# Then the text can be printed as output and be verified by us
print(text)

Then save your code into your favorite notepad, and save it.

Then update the code, to make it fail with an AssertionError.

Extra: if you want more challenge, you can try to add an improved error message.

Conclusion

Let’s wrap up our journey into Test-Driven Development (TDD), shall we? 🚀

So, here’s the scoop: Test-Driven Development (TDD) offers a structured approach akin to the scientific method, providing a framework for software development that prioritizes clarity, predictability, and reliability.

Picture this: before we even start writing the actual code, we write tests to describe how we want our software to behave. It’s like drawing a map before going on a big adventure – it helps us know where we’re going!

And here’s where things get really cool: we use something called assertions to check if our code works the way we want it to. It’s like having a super fast and precise robot double-checking our work to make sure everything’s OK! 🤖✅

TDD not only makes testing super fast and easy, but it also helps us understand our coding problems better. It’s like putting together a puzzle – each piece fits together perfectly to create something awesome!

So, as we dive deeper into coding and keep exploring TDD, let’s make assertions our best friend. They’ll help us build super strong, super reliable software that can handle anything life throws our way! 💪🌟

Congratulations – Lesson complete!