How to break up unit test suites?

Question

C++ / C#

Please clarify what you need to be guided by and what question to ask in order to make a decision that you need to write a new set of unit tests instead of adding tests to one of the existing ones.
By a set of tests, I mean the English-language "Suite". That situation when we bind tests to some named space. To do this, we can use the BOOST_AUTO_TEST_SUITE macro in case of using Boost.Test or the first parameter TEST/TEST_F in case of using GoogleTest, etc. etc..
I have the following situation and it is not clear to me whether it is worth creating a new test suite or not?
I write code for working with the PE32\PE32+ executable file format and cover this code with unit tests. One important algorithm is converting Rva to FileOffset, often referred to as RvaToRaw() or ImgRvaToOffset(), there are other names. This algorithm should work on both 32-bit and 64-bit images, and there are also several nuances associated with the SectionAlignment, FileAlignment values ​​in the header.
The question arises: How to organize sets of unit tests to test this algorithm?
So far I see the following options:
1. Create a set named RvaToRawTest and various tests in it, for example: when32image, when64image, whenSectionAndFileAlignmentEquals, etc. etc.
2. You can create several sets RvaToRawImage32Test, RvaToRawImage64Test, RvaToRawSectionAndFileAlignmentImage32Test, RvaToRawSectionAndFileAlignmentImage64Test
3. You can create a test set based on the fact that tests need an image with a specific situation, for example, SectionHeadersIncomplete32Test and SectionHeadersIncomplete64Test There
are a lot of alternatives, but you need to stop at one thing. Share your experience please! ;)

Answer 1

I usually follow exactly the same considerations as when creating classes. Those. connection and engagement.
Those. only if the blow-up for many thousands of lines does not come out, I would use the first option. Otherwise, we are sacrificing architectural beauty for readability, that's all.