Ease usage of Fuzzers outside of parameters

[DevSavvySerge]

Currently, the Fuzzers helper class provides convenient static functions for use as test method parameters, for example:

@GdUnitTest
func test_example(rand_int := Fuzzers.rangei(0, 100)):
    assert_true(rand_int in range(0, 101))

However, using these fuzzers outside of parameterized tests (e.g., directly within test logic or custom scripts) can be cumbersome since the static methods all return the base Fuzzer type instead of the specific subtype (StringFuzzer, IntFuzzer, etc.).

This means that the returned object handles data as a generic Variant, losing the strong typing and specific features provided by the concrete fuzzer classes.

✅ Benefits

• Enables easier use of fuzzers outside of test parameters.
• Preserves type safety and editor autocomplete (type hints).
• Makes fuzzers more flexible and reusable in custom fuzzing scenarios or dynamic data generation.

[MikeSchulze]

Hi @DevSavvySerge,

As far as I understand, you want to receive the fuzzing value directly as a function argument and not the fuzzer instance.
Yes, that would be much more intuitive, but unfortunately it would also involve increased effort for parsing the test arguments. The parser would then have to recognize, for example, that a fuzzer is specified as a function.
In addition, the fuzzer execution would have to be rewritten, which would mean a fundamental change to the existing API.

All of this would involve a lot of effort and would also destroy the existing API.

When I introduced the fuzzer, I opted for the easier way, which is certainly not optimal but functional.

Therefore, implementing this feature would take time that I don't currently have.

[DevSavvySerge]

Not exactly what I had in mind but you're up to something even better than what I had in mind.

Here was my exact case:

I had to write:

var loaded := [StringFuzzer.new(10, 15).next_value(), StringFuzzer.new(10, 15).next_value()] // Array of String

Where I could have written:

var loaded := [Fuzzers.rand_str(10, 15).next_value(), Fuzzers.rand_str(10, 15).next_value()] // But it's not an array of String

Which was not a huge game changer.

[MikeSchulze]

You cannot use a fuzzer in this way.
The use of fuzzers is defined as injection and does not allow any other syntax.
func test_foo(fuzzer := Fuzzer.foo()) -> void

Can you please attach a complete example of exactly what you are doing?

[DevSavvySerge]

Sure

func test_load_resource_WhenCalledAndLoadingAlready_DoNotAddToResourcesLoadingOrStartsLoading() -> void:
	var sut = mock(GlobalReduxSlice, CALL_REAL_FUNC) as GlobalReduxSlice
	var path := StringFuzzer.new(10, 15).next_value()
	do_return(true).on(sut).__is_loading(path)

	sut.__load_resource = [StringFuzzer.new(10, 15).next_value(), StringFuzzer.new(10, 15).next_value()] as Array[String]

	var expected = sut.__load_resource.duplicate()
	
	sut.load_resource(path)

	assert_array(sut.__load_resource).contains_same_exactly(expected)
	verify(sut, 0).__load_threaded_request(any())

[DevSavvySerge]

I know I could use one injected the Fuzzer, but it's not the way I like to structure my code.

[MikeSchulze]

Okay, that completely contradicts the actual purpose of the fuzzer as a test argument.
Please read the documentaion

The way I see it, they're misusing the fuzzers for their test setup here ;)

[DevSavvySerge]

You wrote nice tools for generating random piece of data.

I'm glad I can use them outside of an opinionated pattern. And the situation is not bad as is, but I guess it would be handy to have shortcut which skip the two step 1) Generate a Fuzzer 2) Ask for next value.

[MikeSchulze]

You are welcome to use the fuzzers in your test, but this is not the intended use case ;)