Let's install the package for our project, which is called Fluent Assertions.
So let's go ahead to Tools NuGet Package Manager, Manage NuGet packages for Solution.
And on the left side, click on Browse and search for fluent assertions.
So you get that.
Here you can see 164 million downloads.
So yeah, it's getting used a lot and you want to use that too.
So let's install that for our testing project.
And our testing project is the calculator test, right?
So because well, we will use those fluent assertions inside of our tests.
So we only need that for the testing project.
Simply hit install and if there are any licenses to agree on, do that.
Now once that's done, you can close the solution.
NuGet Explorer here.
Go to the unit test Again, let me just get that view right and start using fluent assertions.
So and as I said in the earlier video, we want to get rid of the if statement here because that makes
our code look a little bit messy.
And what you will see now is super cool.
So let's just get rid of the complete if statement here.
And what we can simply do is we can say result dot should dot be for and this is so much cooler and
shorter and easier to read than the if statement.
So our result should be four.
Well, how much easier could it be?
Right?
So it's absolutely human readable in the very best possible way.
But what error message do I see if the test fails?
Let's switch over to our calculator again and one more time we will return five.
So let's save it.
Go to the unit test right click and start our test.
Always make sure to actually really run it where you can see that we have now also a nice message expected
result to before but found five.
So the message is not as clear as the one that we have wrote.
But however, look at the test methods name it's sum of two and two should be four and the error message
is expected result to be four, but found five.
So the method name and the error message together will give us enough information to quickly understand
the problem and fix it.
Right.
So taking the message and the actual name of the method will give us enough information so we can still
assume that something inside of the sum method here logically is wrong.
Again, let's fix it.
Go to the calculator, remove that line of code, bring in the original correct code, save it, rerun
the test.
Now let's clean up the test code and remove the unnecessary noise to make it as readable as possible.
Let me just close the test.
Explorer here and let's shorten that up.
So instead of using the curly braces, we can simply go ahead and say goes to new calculator.
And that calculator calls dot sum two and two.
This results in an integer and we say that integer should dot be four.
Okay, so I guess you cannot even simplify it more than that.
From a functional perspective.
It's exactly the same thing for sure, but it's easier to read and even shorter.
Now let's keep this practice.
Go to the calculator, to the functional side.
Let's do exactly the same thing.
Remove the curly braces goes to.
Left plus right, returning it automatically.
There we go.
It's easy as that.
However, this is not really related to TDD, but well, software designing in general.
Finally, move over to the unit test and let's get rid of that really unmatching class name instead
of calling it unit test one right click, rename it to calculator tests.
There we go.
That's definitely looking way better now.
Awesome.
So let's just recap this now.
Allow me to bring you an example.
However, first of all, thanks a lot for Jonathan Dubon for that nice image.
We grabbed it from Unsplash, so we are mentioning the creator here.
Thanks again.
However, guitar tuners are devices that help guitarists to tune their guitars right.
Guitarists should adjust the knobs to get the sound the tuner expects.
You can think of a tuner as a test and the guitar sounds tunefulness as the production code.
Before the guitar is tuned, the tuner knows how the notes should sound, so the test knows how the
actual result should look like.
Then the guitarists adjust the knobs based on the tuners lead until the guitar sound satisfies the tuners
expectations.
So you got the tests which know how the result should look like, and you adjust your source code,
your actual functional code to match the tests expectations.
So this analogy demonstrates how the test first development works.
Before you write any production code, you first write a code that specifies how the production code
is expected to work.
The first rule of TDD is to write production code only to pass a failing test.
Writing tests before writing production code is called the Test First Approach.
And in chapter one, we have now finally reviewed the manual testing process.
We created a test project and wrote the first automated test.
Then we moved on and removed the code and everything from scratch based on the test.
First development, we talked about writing good assertion messages and wrote an excellent assertion
message for the test we had written.
Finally, we installed the Fluent Assertions Library and used it in our tests.
So congratulations on watching the first chapter completely.
Now you can write an automated test and it's your turn to take action.
We went through a practical introduction to TDD now and in the next chapter we will continue with some
theories along with some real world examples.
And if you are not watching this course from our all access subscription.
So if you, for example right now on YouTube, you might want to go ahead into the all access subscription
so that you get personal tasks.
So we got some tasks and exercises prepared for you and you can grab them there.
Also, we got some nice handouts so that you got all the information really in a nice format and you
can sign up for that All access seven days for free and start right away.
So if you are already in the all access subscription, good job.
If you are not, go ahead and sign up right now.