Let's get started with chapter two of test driven development in C Sharp.
In the last chapter, we started with a practical introduction to TDD and now we are going to start
with and now we are going to start with some more theories and see them in practice.
At the end of Chapter Two's presentation, you will have learned why writing tests first is important.
What are test preconditions?
And the red green refactor pattern software development is building solutions for some of the stakeholders
problems.
To build high quality software, you should think before starting to write any code, you should understand
the problem in depth, then design a solution out of it before starting to implement the body of a function.
For example, you should know which parameters clients should pass to it and what the consequences of
calling it is.
In other words, you should know what you expect the functions to do, not how the function does it.
TDD experts think and make the expected requirements as explicit as possible.
Then they start implementing the production code until the production code meets the actual expected
requirements.
Well, sounds confusing.
No worries.
We will see what it means.
Imagine that you want to write a division function before starting to write the body of the function.
You should consider what parameters clients should pass to it and what the division function would return
to the clients in turn.
For example, four divided by two should be two.
This is the behavior that all clients expect from the function.
This expectation is a test scenario.
Whenever you want to write a production code, you should think about three things.
What is the input of the code you want to implement?
What is the outcome and which function, method or class should receive the input and conclude the output.
Imagine that you want to test if a car ignition works correctly.
When you start the ignition you should hear the car engine sound.
The input is starting the ignition and the outcome is the engine sound.
If the test scenario complete, what if the car doesn't start because it has no gas?
Does that mean that the ignition does not work?
Obviously not to test the ignition.
The car should have gas.
We should always fill the tank before trying the ignition.
Filling the tank is the precondition in that scenario.
A precondition is a part of the test scenario.
Any test scenario can have zero to multiple preconditions.
Some test scenarios may have no preconditions, but every test scenario should have an input, a system,
run the test and an outcome.
So let's continue with the real world example because that's most of the time way easier to understand.
Imagine a flight booking application like we have built it in our 21 day ASP.Net Core and ASP course.
When I book a flight, the number of remaining seats should be reduced.
As a passenger, how many seats should remain bookable for the flight?
If I book one seat?
Well, it depends on how many seats the flight had when I was booking it.
So something is missing from this test scenario.
It requires a precondition.
We need to define the initial seat capacity of the flight before booking it to be able to check if the
book method reduces the number of seats of the flight object correctly.
So now we have a complete scenario.
So let's get our hands dirty and implement it directly inside of a new project.