Provide different test packages (funcs) for test types generation #232

New issue

Open

opened 2025-12-28 18:07:31 +00:00 by sami · 4 comments

sami commented

2025-12-28 18:07:31 +00:00

Owner

Originally created by @carpawell on GitHub (Aug 20, 2024).

I'm always frustrated when I have to debug problems that are related to the randomness of a type I get from test packages. I want to test my code and be sure I get some real values, not calculating the probability of how real a value I get is and if it suits me.

Describe the solution you'd like

A single package (or a separate function) for real random test values, and a single package (or a separate func in the same package) for values that are correct, predictable, and can be used safely in the test code.

Describe alternatives you've considered

No. SDK test packages are (and will be more if we do not change them) unusable in almost all unit tests if they generate random things.

Additional context

https://github.com/nspcc-dev/neofs-node/issues/2917 existed and took some time only because of the random checksum.
Also, I do know that https://github.com/nspcc-dev/neofs-sdk-go/pull/610 was not fully agreed and there are some thoughts that it should not be this way.

Originally created by @carpawell on GitHub (Aug 20, 2024). ## Is your feature request related to a problem? Please describe. I'm always frustrated when I have to debug problems that are related to the randomness of a type I get from test packages. I want to test my code and be sure I get some real values, not calculating the probability of how real a value I get is and if it suits me. ## Describe the solution you'd like A single package (or a separate function) for real random test values, and a single package (or a separate func in the same package) for values that are correct, predictable, and can be used safely in the test code. ## Describe alternatives you've considered No. SDK test packages are (and will be more if we do not change them) unusable in almost all unit tests if they generate random things. ## Additional context https://github.com/nspcc-dev/neofs-node/issues/2917 existed and took some time only because of the random [checksum](https://github.com/nspcc-dev/neofs-sdk-go/blob/256513c1b29bbb59326eecdc0ae669cc67e33155/checksum/test/generate.go#L17-L18). Also, I do know that https://github.com/nspcc-dev/neofs-sdk-go/pull/610 was not fully agreed and there are some thoughts that it should not be this way.

sami added the

bug

labels

2025-12-28 18:07:31 +00:00

sami commented

2025-12-28 18:07:31 +00:00

Author

Owner

@carpawell commented on GitHub (Aug 20, 2024):

In fact, I do not know where a real random type can be used. Mb in a fuzzing test.

@carpawell commented on GitHub (Aug 20, 2024): In fact, I do not know where a real random type can be used. Mb in a fuzzing test.

sami commented

2025-12-28 18:07:31 +00:00

Author

Owner

@roman-khimov commented on GitHub (Aug 20, 2024):

Tests must be predictable. Randomness is rarely required there.

@roman-khimov commented on GitHub (Aug 20, 2024): Tests must be predictable. Randomness is rarely required there.

sami commented

2025-12-28 18:07:31 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Aug 23, 2024):

for values that are correct, predictable, and can be used safely in the test code

its impossible to cover all test-specific and context-dependent cases, _correct_ness is too relative. If tested code works with particular data, test code must specify it explicitly. If a test is not robust to randomization, it should just not use it

tests will be more clear if they create instances themselves, rather than pulling them from a closed box. With the exception of rare but existing tests that work with any data

@cthulhu-rider commented on GitHub (Aug 23, 2024): > for values that are correct, predictable, and can be used safely in the test code its impossible to cover all test-specific and context-dependent cases, _correct_ness is too relative. If tested code works with particular data, test code must specify it explicitly. If a test is not robust to randomization, it should just not use it tests will be more clear if they create instances themselves, rather than pulling them from a closed box. With the exception of rare but existing tests that work with any data

sami commented

2025-12-28 18:07:31 +00:00

Author

Owner

@carpawell commented on GitHub (Sep 6, 2024):

nspcc-dev/neofs-sdk-go@3d4a462485/object/test/generate.go (L49-L53)

This just pissed me off again: a tombstone object with 1, 2, 3 payload, an incorrect object for sure. I do not understand why I have to fix it in my test code.

@carpawell commented on GitHub (Sep 6, 2024): https://github.com/nspcc-dev/neofs-sdk-go/blob/3d4a462485d427f15c26a1f8a31873dcc9500cd6/object/test/generate.go#L49-L53 This just pissed me off again: a tombstone object with `1, 2, 3` payload, an incorrect object for sure. I do not understand why I have to fix it in my test code.