Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Creating Unit Tests | Unit Tests
course content

Conteúdo do Curso

Java JUnit Library. Types of Testing

Creating Unit TestsCreating Unit Tests

Let's get started with some hands-on practice and finally start writing Unit tests using the JUnit library. We will be testing the not-so-complex method filterAndSortPalindromes, which returns only the strings that are palindromes (read the same forwards and backward) and then sorts them by length in descending order. A class with such a method will look like this:

Note

Please note that in this course, we will exclusively use a functional STYLE of testing, which we will conduct using Unit Testing.

Here, we are using the Stream API to process a list of strings. We have also written an additional method, isPalindrome, which checks whether a string is a palindrome. Then, we sort the strings in descending order of their length to obtain structured information.

However, what interests us is not the functioning of this method itself but its testing.

First, we need to create a test file for this method, and it is done as follows:

The first thing you can notice is the "@Test" annotation. We use this annotation to indicate methods that are unit tests. In our case, the method filterAndSortPalindromes is marked with this annotation and serves as a test. You should apply such an annotation to every method that is a unit test.

What interests us is precisely how we will test it:

The first thing we need to do is understand the algorithm of actions. It's quite straightforward here. We have two parameters: "actual" and "expected." "actual" will store the result of the method's execution, while "expected" will store the expected result from the method.
For example, let's write a test input for the test in the form of a list of strings:

This list contains strings, some of which are palindromes.

The method should sort this list in a way that only palindromes remain in it and also sort them in descending order by length. In other words, the expected result after using the method is a list: ""radar", "level", "madam"."

Let's create an "expected" list with these values:

Next, we need to create an "actual" list. This list will be the one returned by the method after it has successfully completed its operation. Working with this list is straightforward; we simply assign it the result of the method executed with the "input" parameter.

Now, we have lists for comparison. To test the method, we need the "actual" list to be identical to the "expected" list. To achieve this, we can use the "assertEquals" command, which compares two objects, and if they are equal, the test passes successfully.

Note

In the JUnit framework, there are many different assertions, such as "equals." Later in the course, we will also cover some of them.

Great, the unit test is ready, now all that's left is to run it:

So, we have written one unit test for our method. But you remember that we need to create not just one test but one unit test for each of the cases. Therefore, in the next chapter, we will also implement other test cases for this method.

Unit testing is not complicated but can be time-consuming work because you spend time brainstorming test cases and writing them out.

Tudo estava claro?

Seção 2. Capítulo 3
course content

Conteúdo do Curso

Java JUnit Library. Types of Testing

Creating Unit TestsCreating Unit Tests

Let's get started with some hands-on practice and finally start writing Unit tests using the JUnit library. We will be testing the not-so-complex method filterAndSortPalindromes, which returns only the strings that are palindromes (read the same forwards and backward) and then sorts them by length in descending order. A class with such a method will look like this:

Note

Please note that in this course, we will exclusively use a functional STYLE of testing, which we will conduct using Unit Testing.

Here, we are using the Stream API to process a list of strings. We have also written an additional method, isPalindrome, which checks whether a string is a palindrome. Then, we sort the strings in descending order of their length to obtain structured information.

However, what interests us is not the functioning of this method itself but its testing.

First, we need to create a test file for this method, and it is done as follows:

The first thing you can notice is the "@Test" annotation. We use this annotation to indicate methods that are unit tests. In our case, the method filterAndSortPalindromes is marked with this annotation and serves as a test. You should apply such an annotation to every method that is a unit test.

What interests us is precisely how we will test it:

The first thing we need to do is understand the algorithm of actions. It's quite straightforward here. We have two parameters: "actual" and "expected." "actual" will store the result of the method's execution, while "expected" will store the expected result from the method.
For example, let's write a test input for the test in the form of a list of strings:

This list contains strings, some of which are palindromes.

The method should sort this list in a way that only palindromes remain in it and also sort them in descending order by length. In other words, the expected result after using the method is a list: ""radar", "level", "madam"."

Let's create an "expected" list with these values:

Next, we need to create an "actual" list. This list will be the one returned by the method after it has successfully completed its operation. Working with this list is straightforward; we simply assign it the result of the method executed with the "input" parameter.

Now, we have lists for comparison. To test the method, we need the "actual" list to be identical to the "expected" list. To achieve this, we can use the "assertEquals" command, which compares two objects, and if they are equal, the test passes successfully.

Note

In the JUnit framework, there are many different assertions, such as "equals." Later in the course, we will also cover some of them.

Great, the unit test is ready, now all that's left is to run it:

So, we have written one unit test for our method. But you remember that we need to create not just one test but one unit test for each of the cases. Therefore, in the next chapter, we will also implement other test cases for this method.

Unit testing is not complicated but can be time-consuming work because you spend time brainstorming test cases and writing them out.

Tudo estava claro?

Seção 2. Capítulo 3
some-alt