When a test fails, the error message should explicitly indicate what went wrong.
Because imagine that you have hundreds of tests in your application and this is absolutely common practice.
So a subset of these tests is failing due to the recent modifications of the code.
You should be able to quickly figure out the reason.
Right?
So now for a quick test, let's simply go ahead and return five from our calculator sum method.
So go into the calculator here.
We got some method.
Let's just comment that out and let's simply return five, which is obviously wrong, right?
Because first of all, we don't use left and right.
But however, when we go to the test, you can see that we expect the result to be four.
And if not, we throw an exception.
And since Sum is now always returning five, it doesn't really matter what we enter here.
So in fact our test will fail.
Let's right click run tests again.
Let's open up everything what we got right here until we come to the actual testing method.
And you can see that the message right here is system exception, exception of type system exception
was thrown.
And this is because if we run into an issue, we throw an exception here, which is absolutely not really
saving us anything then well, there is an error, but we don't provide any information.
Right?
In fact, it tells us nothing about what went wrong and the reason that the test failed.
So let's actually throw a more useful error message inside of the parameter here.
We pass in a formatted string, let's say the sum we can hardcode this because that's our testing scenario.
It's also hardcoded in the method, right?
So that's absolutely no problem.
The sum to two was expected.
Expected to be four, but it's and then pass in the result.
So this is some useful information actually which helps us to fix problems in our application depending
on whatever we return or we get as a result from our test.
So let's rerun the test just one time and now you can see system exception.
The sum to two was expected to be four, but it's five.
So right now we have a really nice well exception message which also tells us about the actual result
and what we are expecting.
So this is nice and it directly indicates that the calculation of two and two here, anything there
is wrong.
So our testing scenario would be two and two is four and the outcome was five.
So anything here was absolutely programmed in the wrong way.
However, we don't need to use two and two should be four.
We could also go ahead and say ten plus ten should be 20 or 1000 plus 500 should be 1500.
Right?
So everything here, which adds two numbers would work fine, but you have to think about one specific
test scenario.
Just think about it.
What could a user enter and what would be a valid result?
So a user types in two and two and the result should be four.
That's a valid testing scenario.
However, the assertion message, that's the message we're getting right here from the test is specific
and unique now.
So I understand the exact reason for the test failure as soon as I look at it and now we are able to
fix it so we can see that this sum method is wrong.
Let's go into it and we can see that we are returning five here and that's not correct.
So we directly come to the right point.
Let's bring in the correct logic here, right.
So we can save it.
And again, if we change something, you also want to pay attention on that here, right?
So you can see it's not passing, but we want to make that pass.
So let's run the test again after fixing the issue or after we think that we fixed the issue.
And you can see that when you start or restart the tests, everything is working now and that the test
has passed successfully.
Awesome.
Now there's still a lot to improve and we really want to teach you the best way.
So inside of the unit test, you can see that if statement here and well those if statements make the
code base make the code base look complicated.
So what we do next is we install a library to remove the if statement from our test and clean up the
test code.
And for that we will use the so-called fluent assertions.
So let's dive into that.