From the course: Programming Foundations: Test-Driven Development

Writing test cases - Java Tutorial

From the course: Programming Foundations: Test-Driven Development

Start my 1-month free trial

Writing test cases

- [Instructor] Writing good test cases requires a set of tools, techniques, and conventions. Let us look at some of these to write a simple test case. Let us say our requirement is to find how many times an alphabet appears in a word. So if the word is pizza, Z appears twice whereas X appears zero times. So let us start with a project, 0005. I have two packages: main and test. I'll keep my code in the main package and test cases in the test package. This is the first convention. Keep your code and test cases separate to manage your project better. When you ship your code in the final --, you don't want your test files to accidentally get tagged along. Next, I will create my first test case by right clicking and choosing JUnit Test Case option. And I name this as "TestHangman". This brings up the second convention. It is better to indicate that this is a test case class. Some programmers put the word "test" as a prefix, others as a suffix. The argument is that TestHangman sounds like a word, and HangmanTest is a noun, which is what a class name should be. However, I prefer to see the word "test" before any names so that I know it contains tests. Whichever option you choose, make sure you remain consistent. Now Eclipse tells me that JUnit library is not in the build path. I accept the suggestion to add it to my test case class, and now I have my first test case stub ready. I want to test that Hangman returns how many times an alphabet appears in a word. So I will call my test case as test_alphabetCount. In fact, I can make alphabetCountInAWord. If you're wondering that the method name is too long, then here comes the third convention. Name your methods meaningfully to indicate what they are testing. Even if the name sounds a little too long. You will never have to retype or even remember this name because it will never be directly called by you. It will be called by the JUnit test runner. So it is okay if the name sounds a bit of a mouthful. Now in this method, I'll say "String word," and some string value, and a character variable, alphabet, as some alphabet that I want to count. Now I instantiate hangman as new hangman. Obviously, this will give a compilation error because there is no such class yet. So I accept Eclipse's suggestion to create the class. I have to make sure that I create it in the right folder. I choose Main, and Eclipse creates the class for me here. Coming back, I will now store the count from the hangman's count alphabet method, to which I want to pass the word and the alphabet to count. Once again, at this point, Eclipse gives a compilation error because there is no such method. So I choose Create Method option, and I accept the public int countAlphabet signature here. At this point, you will notice that I'm accepting the suggestion to create this as a public method. That is because I want my test cases from another package to be able to access the method. But sometimes you may have some methods in your code that need not or should not be public. How to you test those? Well, the idea is that your private methods will be used in some other method of your class that are public. So instead of testing your private methods directly, you test those public methods that use the private methods of your class. So let's go back to test Hangman, and here, finally I make the first assertion as assertEquals one, which is the expected value, and count, which is what I'm testing. Before we move on, let's talk about assert statements a bit. Most programming languages have an assert statement used for defensive programming to ensure that a certain condition is true at a given point of time in the program execution. If the condition is not true, the program will show an assertion error. JUnit 5 has a class called "Assertions" that has many assertion statements as static methods. To use any of these assertion statements, you simply import the assertions class from the Jupiter API. You will learn more about these assertions later in the course. Back to our test case. Here, the test case seems complete. If I run it, I get the red bar. Now I go to Hangman and change the code to make the test case pass. For that, I say int result equals zero, which is where I'll store result. And then in a loop, for each char C and word toCharArray. If C equals the alphabet that I want to count, then result plus plus, and finally return result. I run my test again, and we are green.

Contents