If you Google what test driven development is, you will see lots of short descriptions, but you can
actually not get anything from them.
The definitions are not wrong and you're also smart enough.
But the problem is that TDD is like nothing else.
You have learned about software development before and it's not introducing a bill with only a couple
of simple sentences.
So rather than starting with a theoretical introduction, I will walk you through a practical introduction
to TDD.
So let's start with something familiar.
What is manual testing?
How do we test our application?
Well, first of all, we write some basic code, then run it and test.
If it works as expected, then we may find some bugs or the requirements may change.
So we finally have to change the code, run it again, and so on.
The problem is that you may break some working features every time you modify the code and to make sure
that the program still works as expected.
You have to test all affected features each time you change the code.
And that's very time consuming, right and undependable.
Each change you make to code in that situation makes you less confident, the less confidence caused
worse development experience and less productivity.
And on the other hand, the time you need to spend testing grows exponentially, and each time you run
the application, you might forget to test something important.
Now you might ask if there is a better way.
And of course there is.
And that's why we are here, right?
Rather than testing everything manually, by each time you modify the code, you can write some code
to test the most critical parts of your program so that every time you change your code, you simply
run the code that tests it.
And that's much faster and way more reliable.
No worries.
It's simple.
I will describe it again using an example right now.
Imagine an application that sums two numbers.
Well, how do you test it?
After you run it, you input two numbers and click the sum button.
What should you see as the sum of two and two?
Well, it's obvious for for sure that you know what you should see as the result.
You can write some code to test it instead of testing it manually.
Let's take a look at the sum function which handles the logic behind this user interface.
Regardless of its technology.
Let's write some code that tests the sum function behind the user interface.
Forget about UI technology just for now.
This is the core logic of the application.
You want to test this, let's write some code to check if the sum function works as expected.
This is the same test as the one we did manually and it's automated.
I can run it every time I change the sum function and it throws an exception As soon as I break this
behavior, let's move the test code to a method.
This is called a test method.
We call the sum method, the system and the test in this context.
So test methods test whether the system under test satisfies an expectation successfully or not.
And we expect the sum of two and two to be four.
You can see the name of the method here explaining exactly what should be tested, right?
So just forget about all the complex terms.
We have a simple test method which tells us exactly what we want to test inside of the logic of that
method.
And then we simply call our sum method, passing in the parameters and check for the result and automatically
calling this test method in automated test.