Faker().text().text(1, 64, true, false, true) returns empty String when length is 1

[axelfontaine]

Describe the bug
Faker().text().text(1, 64, true, false, true) returns empty String when length is 1.

To Reproduce

(1..1000).forEach { _ -> check(Faker().text().text(1, 64, true, false, true).isNotEmpty()) }

Expected behaviour
A fake text according to the specifications.

Versions:

• JDK: 24
• Faker Version: 2.5.0

Additional context
It happens here: https://github.com/datafaker-net/datafaker/blob/main/src/main/java/net/datafaker/providers/base/Text.java#L206

[asolntsev]

@axelfontaine From your side, the mistake is parameter "1". The minimum length cannot be 1 because you expect your password to contain at least two symbols (upper case and digit). So this code would work correctly:

Faker().text().text(2, 64, true, false, true)

From DF side, we can make a fix so that expression Faker().text().text(1, 64, true, false, true) always generates a string of length 2..64

[axelfontaine]

@asolntsev The contract as it stands now is really ambiguous. It is easily interpreted as a random string between this and that length, drawing from a pool of both lowercase letters and digits. From your comment and the code, I understand you meant something else. You may want to clarify that in JavaDoc to avoid this kind of confusion in the future.

[erikpragt-connectid]

From DF side, we can make a fix so that expression Faker().text().text(1, 64, true, false, true) always generates a string of length 2..64

We could do that, but then someone will report a bug that the generated length would never be 1, even though they explicitly said it should be 1...

[asolntsev]

someone will report a bug that the generated length would never be 1, even though they explicitly said it should be 1...

Now it's a question of definition.
For me, it seems reasonable to read faker.text().text(1, 64, true, false, true) as "generate a random string NO SHORTER than 1 and NO LONGER than 64". For me, it's totally OK if it never returns 1-length string.
Just describing it explicitly in javadoc is good enough.

Alternative is to throw IllegalArgumentException (because 1 is not possible with (true, false, true) parameters). But it's a breaking change, and it may cause headache for many users.

[axelfontaine]

Once the contract is made explicit in JavaDoc, rejecting invalid input and not producing invalid output seem perfectly fine to me.

[kingthorin]

as "generate a random string NO SHORTER than 1 and NO LONGER than 64". For me, it's totally OK if it never returns 1-length string.

I can agree with this