So here we have now all of the tests just for the booking reduces the number of seats.
And yeah, it's okay to have multiple tests because they are actually not the logic, so you can just
maintain them.
But for sure, as with some simple logical code or with any logical code, it's easier to maintain if
the code is well, not repeating.
Right.
So it's totally fine to do that because it's about testing, not about functionality, that's fine.
But in that scenario here where we only switch those well magic numbers of variables inside of that
test, we can go ahead and create a parameterized test instead.
So because right now every test here is exactly the same stuff, but only some values have changed.
So instead of doing that, duplicating it three times, we can create the parameterized test.
However, sometimes you also want to test for a specific scenario, but maybe have a different call
inside here, and that's where you have to duplicate it then and just change the actual functional code.
And not only the value.
So it's definitely fine to copy over tests.
Now let's create the parameterized test to gain some more well maintainability and to simplify our flight
test specifications here.
So the first thing that we have to do, we will start with the first one here and then later copy the
values from here.
So we just focus on the first test.
Booking reduces the number of seats and instead of using the fact attribute, we will now switch it
over to be theory.
So this is from X unit and it tells that some test data is coming from outside of the method.
Next over.
We need another attribute which is inline data.
You can see that directly popping up by eye and if you hover above it provides the data source for a
data theory with the data coming from inline values.
So now let's add some parameters here for sure.
We start with the int seat capacity, right?
So how many seats do we have in the flight?
Secondly, we have the INT number of seats.
So how many seats someone has booked and finally, the result of the remaining number of seats.
There we go.
And we will now use those parameters here.
Seat capacity, we just implement it for the three.
The number of seats is the one, how many do I book, right?
And then the remaining number of seats for sure is the result.
So now inside of our test method, we use parameters, right?
You can see that no magic numbers anymore and we need to provide this data, right?
So we go to the inline data attribute here, add parentheses and simply write down three, one and two,
for example.
So I create a flight with three seats.
I book one seat of it and the result should be two seats are remaining in the flight.
Awesome.
So let's go ahead and run that test.
So run test and that should work and all tests should be passing.
Okay.
And now the cool things happen.
So the test has successfully passed here.
That's fine.
And if we test for another scenario, we simply copy over the inline data and change its values.
So let's see.
What do we have here?
Six, three and three and ten, six and four.
So six, three and three and ten, six and four.
And that totally makes sense, right?
We have six seats available.
We book three.
We have a result of three seats remaining.
We have ten seats available.
We book six, we have four seats remaining.
Make sense.
Now, let me get rid of the other test cases here so we for sure still keep avoids overbooking and book
flight successfully.
Right?
So we now have again three test methods, but our first test method is a theory and a test for three
different scenarios right now, and that will definitely improves our testing code.
Great.
So again, right click on it and run test and you can see that all tests have passed, right?
You can even see five.
So let's open it up.
Fly test flight specification and you can see booking reduces the number of seats and you can see three
test scenarios in here, right?
For each inline data attribute.
Once you can even see the values here on the right side, this is the parameterized test.
And now if we play the devil's advocate game, you can simply create a new test scenario.
So you can if you want to test another scenario, you just create a new inline data and add some new
values.
We have 12 seats available.
We are booking eight of them, so we keep four as remaining.
So and this is all you have to do now to implement a new test scenario for the Devil's Advocate game,
for example.
And that's pretty cool.
Well, look at the parameters that we have passed to this test here.
Why didn't we pass the email as a parameter to seat capacity, number of seats and remaining number
of seats play essential roles in this scenario, but the email address is a dummy in this test.
Right?
As long as the.
Email is valid.
The test passes anyway, so the email has no connection to any other variable in this test scenario.
Only by looking at this test signature you can understand what it does.
If we add the email to the test parameters, the test code's purpose becomes unclear.
This think of dummies as constants and parameters as the variables of the tests.
So remember not to pass dummies as test parameters.