Hello everyone, and welcome to the testing with JUnit 5 or the overview of JUnit testing, how to test with JUnit. We're going to keep going and learning more about how to test with JUnit 5. And we have multiple subjects that we'll be covering in this video here, so let's go ahead and get started. The testing with JUnit and what we're going to be talking about is display name first. So test classes and test methods can declare custom display names, so here's an example how you would do that. So here we have our class, student test instead of calling it student test we could show our display name as test our student. And then, down here when we actually get to our test methods, we have an at test and then at display name. Test the add method and we avoid test one which is not very good naming convention of our test, and we assert that student.addGrade. So this should really be addGrade test or test addGrade, and that would be equal to 3.8, and these tests pass. And then, we have test2 which does not have a display name, and it will just display the test, which again not a good naming convention. So we're going to talk about testing with tUnit and we're going to talk about expected versus actual. So before writing have an expectation of what the code will do, this is one of the biggest advantages of using JUnit. You are forced to consider the what if scenarios before actually writing the code. This allows you to solidify the intentions of your methods. So by writing tests to assert that the methods host conditions are met, this is also why it's critical to have the developer of the code write the JUnit tests for that code. A test of writing the tests after the fact doesn't help the developer consider all the options. So testing expectations. One of the many assert something methods. Use one of the many assert something methods, all of which provide a description which is logged if the test fails. This description should provide information about what failed and why? Remember that JUnit tests may fail years later, so be generous in the information provided in the description. Many of the methods are heavily overloaded. For example, there is the assert equals which I mentioned previously which is the expected value and then you would put a common and then the actual value. Does the assert equals description, expected, and then actual, which will allow the description of what assert that was expecting? The test will fail if the actual is not equal to the expected. The most used method of JUnit on primitives performs a == comparison. On objects, it will perform an dot equals comparison. AssertEquals would probably be your biggest workhorse when using JUnit. But there are more methods, so there's the assertSame which is expected an actual, and the test will fail if the actual is not the same as the expected. And this method only works on objects and doesn't == comparison. So that will check the hash code instead of the dot equals method, And only works on objects. So assertTrue, which is actually so that takes a bowling and fails if the actual is false. And then, assertFalse takes the actual and fail at the actual street, which again it takes a bully. The assertNull which takes an actual fails if the actual is not null and assertNotNull breaks the opposite way. In a grouped assertion, all assertions are executed, and any failures will be reported together. So below, regardless of the first assertion failing, we continue to evaluate assertions in the same assertAll. So assertAll quote calculator is the description, and then we have our lambda test, That test, we're using the assert that method. So calculator right here, it shows our description or a name which is calculator and it has two failures in the assertAll. So we have to assert that calculator.add 2.0 and 3.0. And then, we assume that it's supposed to equal 5.0, but the actual was 5.0. And then, again for the multiply we had 2.0 times 3.0, and we said that it's close to 8.0 with a tolerance of 0.009. But was actually 6 and the difference was more than it was allowed. And then, we have a winky sad face right here. So moving on, so then we can have nested. And so that's going to wrap up this section of the video. We're going to go ahead, and I will see you in the next video as we continue to talk about more assertions. I'll see you in the next video.
