Let's just talk about the red green refactoring.
So we started with translating some requirements to a failing test.
Once we have a failing test, we should only think about how to pass it.
So we write enough production code only to pass the test and not more when the test passed.
We shouldn't start writing the next test yet.
We should think about how we can improve the existing code before we start to write the next test.
So when a test passes, it's the time to refactor the code.
Refactoring means restructuring code without alerting its external behavior.
So the goal of refactoring is to improve the code design.
Once we are done with refactoring, we can think about writing the next test again.
Then the red green refactor is an essential process in test driven development and we will take a look
at that refactoring part right now.
We will start with the red green refactoring by renaming that test method.
So right click on it, rename, let's call it booking reduces the number.
You cannot see it just a second reduces the number of seats.
So exactly what the test should do, right?
Our test for SOA booking here.
There we go.
Reduces the number of seats.
We book something and it reduces from three seats reduce by one to be resulting in two.
So always make sure to give your testing methods the best possible testing name.
Next up, let's switch the name from being public class unit test one to right click rename Flight specifications.
Awesome.
We can save that.
Now we create a new domain class library again, but this time it's for production code.
So right click on your solution and add a new project.
Simply add a class library, hit next, name it domain and then hit next and create it.
Now.
Next up, we will move our flight class into our domain library because right now it's inside of domain
dot test.
But now we want to move it to production.
So we move it to our domain project and not domain test.
So simply right click on flight, you can see quick actions and refactoring.
You can also hit control dot.
So hold the cursor while flight control dot and then you can see that we can move it to a namespace.
So move to namespace, select the target namespace which is domain hit.
Okay.
You can now see everything here has changed, right?
So everything got adjusted and what we now do is we now simply select flight on the right side in the
test project and bring it to domain.
Now this creates a copy, but now we can delete the one from domain test.
There we go.
Now, in that order, if we check flight specifications, you can see that for sure.
He's trying to reference domain tests.
We need to adjust that so that he uses the domain layer instead.
So what we do now is we add a project reference.
So right click on flight, add a project reference, and simply we can remove domain test if we don't
need it for any other stuff later on.
But for now I keep it checked and add the domain reference too.
So hit.
Okay, now we can start using domain and the new flight starts appearing here.
We restructured the code but didn't change its behavior.
Right.
So now we have to adjust 1 or 2 more things.
Go into your flight class and change the name of the parameters of the book method.
So because they are right now, well, not really telling us anything.
Let's call them passenger email.
And for V two we can also use right click and rename and set it to number of seats.
Awesome.
So now we are really using nice parameter names.
Let's go into our test class flight specifications and right click and simply run the test, which should
definitely pass again if we have refactored everything right.
And now that the test passes, it actually tells us that we didn't change the behavior of the code.
And this is exactly what we wanted to achieve because we only were interested in refactoring now.