What is the best way to calculate the expected value in the assertEquals () method in jUnit

Question

I am using the assertEquals() method in jUnit to verify that a specific value is equal to or does not match the actual value that the code generates.

 /* calculating the actual_value */ int expected_value = 1000; // rows of the set of files, manually calculated assertEquals(expected_value, actual_value); 

I am wondering if I will do something like below, this will be a problem in the case of standards and formalities.

 /* calculating the actual_value */ int expected_value = getRelevantLinesOfFiles(set of files); // rows of the set of files assertEquals(expected_value, actual_value); 

since it is practically impossible to find such a variable manually, I wrote a method for reading and calculating the corresponding lines in these files.

My concern is that I am using the out method in the assertEquals method. But the getRelevantLinesOfFiles() method getRelevantLinesOfFiles() not been tested. If I am going to check it, then again I need to manually read the files. So it's the same thing over and over again.

Is this a good practice? or what is the best way to do this kind of testing?

Answer 1

If these files are also the input from which actual_value is calculated, then what you are doing is testing an alternative implementation and a real one. This is true, but requires an understanding of things ahead, for example, this is usually done with a very simple and easy to verify test implementation compared to an optimized and more complex "production" implementation. If this is not the case, you are doing something wrong.

If the files contain results that actual_value not calculated from now, this should be normal, for example, if you have sets of inputs and corresponding sets of the expected result.

Also, consider whether you can overtake at least a few cases of trivial hard-coded input and hard-coded expected output similar to your first example, and not to files. This may require that your interface work with an abstraction that is not File in order to simulate input, or be able to introduce an alternative mechanism for reading files into those tests that actually serve to test the test data.

EDIT: Just to provide a concrete example of using large abstractions instead of File instances (or file names or something else), consider using okio and passing in a set of Source instances.

Real implementation : a list of instances of File , create instances of Source using Okio.source (file) .

Tests : pass a list of Buffer instances containing whatever you want

 Buffer b = new Buffer(); b.writeUtf8("whatever the hell I want in this file"); // can also write bytes or anything else int actualValue = getRelevantLinesOfFiles(Arrays.asList(b)); 

Answer 2

• If the test files are generated only for the test, I think you should carefully prepare these test files manually, for example, 'file1' has 1 line, file0 has 0 lines, and 'fileX' has X lines, etc. you don’t need to prepare too many files, you can just consider some critical cases.

• If these files are real data from the working environment, then I suggest you write a method, for example, getRelevantLinesOfFiles in your code, to calculate the line number from them. but first, you should check this method using the approach mentioned above.

Answer 3

It is always good practice to leave "Magic numbers" (aka 1000) from your code. As talex said, test the getRelevantLivesOfFiles() method on files small enough to count. Then you can use it with confidence to check other parts of your code.