We just wrote the sum function and then we wrote the test code.
So the test we just wrote was a simple example of an automated test.
However, we didn't follow the test driven development approach because based on the TDD approach you
must write the test before writing the actual production code.
So in our next step I will show you what it means to write tests before having any production code and
we will discuss the reason for this later on.
So let's rewrite our sum function using the test first approach.
So that might feel a little bit weird now, but we will now remove the calculator because as I said,
the TDD approach is writing tests before writing the production or the functional code.
So let's really do that.
Okay.
Don't feel sad about that calculator because he will come back later on again.
So simply go ahead and delete the calculator project.
Now inside of our calculator controller, let me just close the test Explorer here we are for sure referencing
it.
However, let's remove the using domain here and var calculator new calculator.
Let's remove the code here and simply throw new not implemented exception.
Right?
So this is also very important.
If you are writing tests, you might stumble across moments where you want to throw a not implemented
exception.
Now finally go to the unit test one class that we have right here and simply keep that empty.
So right now we have a web API project which is like doing nothing and we have a unit test project which
is also clean again, and we have a domain layer which does not contain any element anymore.
You can see that right here.
So now we are good to go to.
First of all, think about our project, then write a test and then write the production code.
Okay?
So don't forget that this is the approach right now.
The first question that we should ask yourself is, what do I want?
And basically this is really something you want to ask yourself as often as possible as a developer.
And many people are not doing it, but you should do it.
Always ask yourself, what do I even want?
What should my program do?
And that specific scenario, we want a some function.
So our next step is to simply think about what our sum function should be able to do.
Well, in that scenario, you might end up with something in your head like, okay, the sum of two
and two should be four, right?
So as I said, it's a very easy scenario, but in TDD it's more about the actual workflow, about the
actual approach, not about the really specific algorithm.
So let's remove our well automatically generated test here.
You could also rename it, but I want to write it from scratch.
So in my head I got that.
Okay, my sum.
You can also write that down for sure or write a comment.
My sum function works like this.
If I add two and two, the result should be four.
So now what I do is I write a test method and write down here an attribute called fact.
Next up, I write down public void and now I really name.
And now I really name the method, the test method as what I have just said.
So sum of two and two should be four.
All right.
So this is super easy to read.
So the method or the code block inside of that test method should really be exactly that.
We will now add two and two and the result should be four.
So this is our test scenario.
Now let's write that down.
Var result equals to sum, and now it becomes a little bit weird because we are writing down code,
which is not existing yet.
Right?
And that might feel wrong, but it's totally fine because we will just solve the error step by step
and that's totally fine in part of the actual approach.
So right now we are writing down a future version of a sum method, which is taking two parameters and
the result should be four.
So let's remove those red lines and make the build pass.
Let's again write down a sum method here based on that information.
So that's very important.
First of all, you think about a scenario, you create that test method, including the name, you write
the actual test code, and then you just get step by step through the red underlines through the errors.
So right now we need to create a sum method.
So we go ahead and create a sum method.
And in that case you have written down the test even before you have written down the logic.
Because right now I'm writing down the actual code block Let's throw a new.
Not implemented exception.
There we go.
So even right now, there is still no logical code.
But actually we removed every red line and our code is working again.
So at the very top I can see I have still that domain namespace integrated.
I will remove it, but now it's working, right?
So we have defined the test and then we added the sum method because we needed to in order to let the
project compile.
And then we don't even care about the actual logic of it.
Let's just think about what should the sum function return?
It should return four.
So let's throw a new exception.
If it does not, if result ain't four.
So if it's not four, we want to throw a new exception.
There we go.
Very easy to follow along.
Now let's start the test.
And the test has to start so our project can compile.
But the test has to fail because we have no actual logic inside of our sum method.
And you can see that it failed and that's totally fine right now.
Now let's follow along on that.
You should know that it's totally fine if it fails because it helps you to write actual good code.
So it's not like you write down everything and it works straight out of the box, right?
You really follow along on those failed tests or error references.
So let's try to make the test pass because that's what we are aiming for.
We should really follow the error guide.
So read the errors and fix them.
Take a look here in the error list.
So open up the dropdown here.
Sum of two and two should be four and you can see some information here.
You could for sure also attach that window anywhere.
You don't have to have it like a pop up as I do.
Go ahead and attach it at the very bottom at Visual Studio.
But that's easier for the videos here.
So system not implemented exception.
The method or operation is not implemented.
Totally makes sense, right?
Because we are throwing a not implemented exception.
So that tells us that we now should go ahead and implement some logic here.
Let's do that.
The algorithm here is pretty simple, as we already have discovered, return left, plus right.
There we go.
So again, we are creating the sum function as a part of our domain model.
So we should move it to the domain library to enable the web application to call it again.
Right.
However, we will do that just in a second.
Let's test again.
So hit, run and this time you can see everything is working here.
Fine.
Great.
So that's very cool.
However, as I already explained in the test project, we have no logical code included or we should
not only test scenarios.
So let's take that some method and bring it into our domain project again.
So inside of our domain project, let's create a new class and let's call it calculator.
Now inside of that calculator, we will bring that sum method.
So let me just copy it and remove it.
Go to the calculator inside of the main layer again and paste it here.
Now, again, we need to make it public so that we can call it later on.
So that's great.
Let's go to the unit test again here and you can see that we cannot call the sum method here because
we need to create a calculator.
So let's go to our calculator and change that from being internal to public for sure so that we can
create instances.
Now switch over to the unit test again and now we can create a new calculator.
So var calculator equals to new calculator.
So let's go ahead, start using domain again.
And inside that namespace we have the calculator.
So new calculator.
There we go.
Now we have the instance of the calculator object and we can simply call calculator dot some awesome.
So now we finished the implementation.
Everything is just as we need it.
We have the test.
No logical code here, only testing scenario and we have the domain layer which again, there we go,
which again contains the actual functional code and we have our web API which we need to finish up now
again.
So what we can simply do is we can simply return new and we go ahead and use using domain again here.
All right, so we call new calculator dot sum and we sum up left and right.
So now we got everything just as it was before, right?
There is no difference at all.
But the approach was completely different This time.
We really thought about what do I want to have?
Then we build out the test and then we build out the method.
Then we added the class.
Then we brought that method into the class and then we wired everything up together again to make everything
working.
And this is the typical TDD test first approach to make sure that everything is running again.
Go to unit test right click.
And run test.
Awesome.
So as you can see, everything has passed.
So everything is working fine right now.