How to write a unit test for a class that works with a file?

Question

Programming

The purpose of the question is to express a request to share the experience of who and how writes unit tests for classes aimed at working with a file that obeys any format?
So.
Now I am writing a library for working with a certain file format, all my unit tests use files in one way or another when checking. I form the file path to the test files in the source code by means of a python script that works out before compilation.
Nota Bene: I deliberately do not specify the development environment and programming language. I am sure that unit testing techniques are not dependent on the language or IDE.
I've been wondering for a while now: What's the best way to organize a unit test that works with a test file?
Options that come to mind:
1) Just put a set of test files in a certain folder and specify the path to this folder for unit tests. I use this method now
2) You can convert test files into a symbolic form, like "\x4a\x4B\xa9" and then you won't need to specify the file path, but in fact these are the same test files, only they are presented a little differently
+ In addition, working with files still confuses me because it looks like an “integration” type of testing, and a unit test should not do this.
PS:
For the time being, I am inclined to think that option two still makes sense, but this means I will have to write a fairly large amount of test code, a kind of Test API for testing my library. Therefore, the question is whether it will be justified, the answer to which the head is still considering?!

Answer 1

It is necessary to separate the logic of reading a file from the logic of its processing - you never know where the data can come from - from the database, over the network, as a method parameter.
Those. the handler must accept a string at the input (or even better, some stream of bytes / characters for sequential reading).
In this case, unit testing will be reduced to testing only the processing logic, and, therefore, the data can simply be written into the test file.
If you also need testing and reading a file, a separate unit test (but since most likely you are using some standard API, you will not need this).

Answer 2

read about mocks and use them. Physical reading from the FS is unnecessary, you are not writing the FS driver, which means you need to test your logic.

Answer 3

Unit tests are called unit tests because they test a unit in isolation. Dependencies, for good, should not be, otherwise it will already be something like integration testing.
However, as often happens, the problem is different) You always need to be sure that a unit test is the best option for you now, since quite often it turns out that writing a functional test is the most profitable and “things in the bag” as they say. This allows you to refactor a large module and not be afraid of constantly falling tests due to the fact that some class has changed api. Functional tests often take much less time, but of course, this is not a silver bullet and unit tests are also needed.
Let's just say that in a vacuum, programmers need unit tests for refactoring, and the customer needs functional tests.

Answer 4

> + In addition, working with files still confuses me because it looks like an "integration" type of testing, and a unit test should not do this.
No one forbids a unit test to read a file into memory before testing and give the tested code a set of bytes from memory or whatever it takes as input. If your code requires a StreamPtr_t object as input (what a strange name), then make a simple 20-line MemoryStreamReader especially for tests.
If you are afraid that the file may be read incorrectly (although this is hardly possible) and break your test, calculate some kind of checksum.
And specifically turning files into footcloths like "\xff" looks like a perversion.