You should still write your UTs in another java file. If all your code is in one single class, "unit tests" are a bit tougher to do, since the entire point of unit tests are testing single classes with one purpose to make sure it does what it should, and not for testing a program as a whole. So you might break out meaningful classes and test the functionality of those classes with unit tests.

Hi @flintwestwood3596, great question! To start, yes, the classes you wish to run unit tests on should ideally be in their own separate .java source code file. This makes it easier to isolate and test each unit of code. And yes, you can definitely write unit tests for a custom class that's in the same java source code file as the main method. To do that, you'll want to create your unit tests in a separate class under the 'test' folder, not the 'main' folder in your project structure.
Remember, the classname for the test file typically matches the classname of the file you're testing, with the word 'Test' appended at the end. So if you're testing a class 'Main' inside the 'main' folder, you'll write your tests in a 'MainTest' class in your 'test' folder. I hope that helps clarify things! Don't hesitate to ask if you have any other questions. Happy coding!

Yep! That's test-driven development (TDD). Depending on the code I'm writing I may do that from time to time, though many people are adamant about doing it all the time.

Absolutely @josueramirez7247! This process is known as "Test-Driven Development" or TDD. The idea is to write tests that fail at first, and to then strive to write the minimal code needed to pass those tests. It's a great way to ensure your code does exactly what you expect, mitigating potential bugs early on. Thanks for bringing that up!

Awesome, I'm glad it helped! And thankful to whomever recommended it!

Hi @yogeshdharya3857, I'm glad to hear that you found the video helpful for your assignment! It's my goal to make content that is easy to understand for beginners. So, it's awesome to get feedback that I'm hitting the mark. I truly appreciate your support and the kind words. Keep engaging and don't hesitate to drop questions if you have any. Thanks for subscribing and stick around for more Java tutorials! Happy coding! 😇👍

Technically to get the coverage tool to show it being covered you just need to trigger each branch of the code, so it can be either. I usually like to have my tests right at the edge cases, so if the code is off by 1 it should break a test. You can of course test both and it doesn't hurt, and often the more tests the better. But you can get a little overly crazy too, so you probably don't need to have tests for every single number from 0 to 100. At some point tests take a long time to run and developers are more likely to skip them, which can defeat the purpose of the tests of course.

Hi @narendramaganti, great question! When it comes to code coverage, it does not evaluate the different possible outcomes of a conditional statement like

Tough without seeing the entire program but I have a guess. The assertEquals method doesn't just take one argument, but right now you're only passing in one argument. The first argument should be the expected value (probably 'F' in this case) and what you have there now (the"actual" result) should be the second argument.

You also need to do a static import of assertEquals to call it that way, otherwise I think it's something like Assert.assertEquals

Hey @gplus46, firstly, thank you for reaching out. In your provided code, there seems to be a mix-up between the class you're testing ('Grader') and your test class ('GraderTest'). 'GraderTest' is meant to be your test class containing unit tests for the 'Grader' class, which should contain the 'determineLetterGrade' method.

From your code snippet, it looks like you are trying to call 'determineLetterGrade' method from 'GraderTest' class instead of 'Grader' class.

Here is how we should call the method in our 'GraderTest':

```java
@Test
void determineGradeF() {
Grader grader = new Grader(); // Creating an instance of the class you want to test, which is 'Grader'
assertEquals('F', grader.determineLetterGrade(59)); // The method being called should belong to the 'Grader' class
}
```
And always remember to make sure that both the 'GraderTest' and 'Grader' classes are in the correct packages so they can recognize each other. I hope this helps! As always, keep coding and don't hesitate to reach out if you have more concerns. Happy coding!

Yep, mocking will probably be covered in a future video at some point

Hi @YD-nd1be, I'm glad you enjoyed the video! Your suggestion to cover Mockito is an excellent one. Mockito is indeed another powerful tool for creating and using mock objects during tests, which complements well with JUnit for a thorough testing approach. I'll definitely keep your suggestion in mind for upcoming tutorials. Thanks for your great input, and keep coding! Don't forget to check out other tutorials and the full Java course. Happy learning!

Well that's essentially what it's doing. But the idea is you can create a whole suite of tests that continuously verify your functionality is correct, so if you happen to make a change at some point down the line, and it breaks that functionality (whether you expect it to or not), you'll have a failing test that lets you know something is wrong.

That's a great question @Leno-2206, and it's quite common for beginners to wonder that! Writing unit tests may seem like a more complicated approach to verifying whether or not your code is working properly, but it has a number of advantages. The first and foremost is that unit tests help to identify bugs at an early stage, which saves a lot of time and effort in the long run. They also document your code in a unique way because they illustrate what a particular method or feature is supposed to do.

It's also important to consider the fact that your code might need to handle a variety of scenarios and edge cases, which can be very diverse. By writing comprehensive unit tests, you can systematically check all possible conditions and exceptions that your code may encounter. You can also refactor, i.e., modify, your code with confidence if you have a comprehensive set of unit tests, since these tests will detect if your modifications have inadvertently altered any functionality.

In the case of function(2,2)==4, it demonstrates that your code works perfectly for one scenario. But there might be other scenarios where it fails, and that's where the unit tests come into play. For more complex methods, manually checking the output each time is impractical and highly error-prone. Unit testing automates this process, making your software more robust and reliable. Keep going with your Java learning journey and all such concepts will eventually become second nature. Thanks for watching!

Awesome, thanks! I just added the ternary lesson earlier this week, glad it's helping! I'll be continuing to add new lessons as I'm able, and anyone who has the course already will of course have access to new lessons that are added as well, forever.
Also with your permission, if you're ok with it, I might also use your very kind words as a testimonial!

Hi @scottmyers6307, I'm thrilled to hear that you're finding my course helpful and learning new things! That's exactly the outcome I'm hoping for when creating these videos and courses. Your feedback is vastly appreciated. And yes, ternary operators can indeed be a game changer! Keep progressing in the course and there's a lot more to learn. Don't hesitate to reach out if you have any questions. Thanks again for your wonderful comments and for being a part of this coding community. Happy coding!

There was quite a bit of material that I could have kept going with, parameterized tests being one of them. (Mocking, TDD, mutation testing, @Before/@After types of annotations, etc.) The video is already quite long so I had to cut it off somewhere. Unit testing is one of my personal favorite subjects though, so at least some of those will probably be the subjects of future (hopefully smaller) videos.

Hi @mtho, thank you for your insightful comment! You make a valid point about parameterized tests, which can indeed make unit tests more robust and efficient. I chose to explain the basics using simple tests in this video to make them easier to understand for beginners. However, I absolutely agree that incorporating more complex unit testing strategies, like parameterized tests, would be beneficial for my advanced viewers. I'll keep this in mind as I plan for future videos, and perhaps, dedicated tutorials on advanced unit testing strategies may be in order. Although my tests were pretty basic, they served to illustrate the concept well enough for beginners. I appreciate your suggestion and thank you for your engagement! Happy coding!