#1659 fix method faker.text().text(1, 64, true, false, true)#1660
#1659 fix method faker.text().text(1, 64, true, false, true)#1660
faker.text().text(1, 64, true, false, true)#1660Conversation
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1660 +/- ##
============================================
- Coverage 92.45% 92.42% -0.04%
- Complexity 3388 3393 +5
============================================
Files 333 333
Lines 6697 6706 +9
Branches 665 667 +2
============================================
+ Hits 6192 6198 +6
- Misses 346 347 +1
- Partials 159 161 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| public String text(int minimumLength, int maximumLength, boolean includeUppercase, boolean includeSpecial, boolean includeDigit) { | ||
| public String text(int requestedMinimumLength, int maximumLength, boolean includeUppercase, boolean includeSpecial, boolean includeDigit) { | ||
| if (requestedMinimumLength > maximumLength) { | ||
| throw new IllegalArgumentException("Min length (%s) should be not greater than max length (%s)".formatted( |
|
|
||
| final int minimumLength = Math.max(requestedMinimumLength, min(includeUppercase) + min(includeSpecial) + min(includeDigit)); | ||
| if (minimumLength > maximumLength) { | ||
| throw new IllegalArgumentException("Minimum number of required characters (%s) should be not greater than max length (%s)".formatted( |
747df61 to
4c4f62c
Compare
|
I'm not sure about this change. If we implement this, suddenly uppercase/lowercase becomes more important than the String length, since when you say: Also, this change would be a breaking change without people knowing it. I'm not a huge fan. Would it be possible to have some validation logic on it? Like if you do: It will throw an exception, since this configuration can never work? (note, this would also be a breaking runtime change without clear communication to our users), some code might suddenly start failing. Perhaps we should keep it as in, and instead make a (validating) text builder or so? |
@erikpragt-connectid
|
91cb744 to
057fa44
Compare
|
@erikpragt-connectid Added javadoc: * @param minimumLength The generated text will not be shorter than this length
* @param maximumLength The generated text will not be longer than this length |
How so? The behaviour of the method changed, and consumers might be depending on this behaviour in their code. Why do you think they won't fail? In my understanding: Should all return a String of 1..64, wouldn't that make a lot of sense? I wouldn't know what this would do though: |
|
@bodiam No, this method works differently. :)
This is the logic usually needed for password generation. |
| * @param includeSpecial is at least one special symbol required | ||
| * @param includeDigit is at least one digit required | ||
| * @return a random string withing given length interval | ||
| * @see Text#DEFAULT_SPECIAL |
There was a problem hiding this comment.
seems need to add a comment that it could throw exception
There was a problem hiding this comment.
Thanks, added @throws javadoc.
... to return a valid string of length 2..64 instead of empty string.
We just don't need to spend so much energy. Let's keep the nature. :)
057fa44 to
7558ba1
Compare
... to return a valid string of length 2..64 instead of empty string.
NB! This PR contains a breaking change: