-
Notifications
You must be signed in to change notification settings - Fork 230
fix generation of phone numbers (domestic/international/mobile) #1225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #1225 +/- ##
============================================
- Coverage 92.35% 92.10% -0.25%
- Complexity 2821 3000 +179
============================================
Files 292 306 +14
Lines 5609 5906 +297
Branches 599 628 +29
============================================
+ Hits 5180 5440 +260
- Misses 275 306 +31
- Partials 154 160 +6 ☔ View full report in Codecov by Sentry. |
I realized that PhoneNumberTest almost didn't test anything: it did 10 iterations, but checked that error count is < 25. :) Now phone numbers are * fully correct for et, bg, mk, md, al, ru * partially correct for most countries (77% errors tolerance) * other countries are marked as FIXME.
| assertThat(phoneNumber.cellPhone()).matches("(044 )?\\(?\\d+\\)?([- .]\\d+){1,3}"); | ||
| assertThat(phoneNumber.phoneNumber()).matches("\\(?\\d+\\)?([- .]\\d+){1,3}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The groupings may as well be non-capturing where possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kingthorin I agree, but now I feel out of resources to refactor these old regexp as well. :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem
| } | ||
|
|
||
| private static Arguments args(Locale locale, String phoneNumberRegion) { | ||
| return args(locale, phoneNumberRegion, (int) (COUNT * 0.77)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought you said 66?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may be also extract into a var to be able to change everything at one place in case of need?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought you said 66?
Yes, initially I put 66%, but later had to increase this number to 77% because of flaky tests failed on CI. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extract into a var
Yes, I've extracted 77% to a constant.
| private static Arguments args(Locale locale, String phoneNumberRegion, int allowedErrorsCount) { | ||
| return Arguments.of(locale, phoneNumberRegion, allowedErrorsCount); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we just import static for Arguments and then it could be shorter like
of(locale, phoneNumberRegion, allowedErrorsCount);?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's shorter, but is it really readable?
When I read just "of(xxx)", how can I understand what this "of" means"? Of what?
Compared to that, Arguments.of is more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it depends on the context
if we are talking about of in general then I would agree it is questionable, however here we are in test class, in arguments provider method, with this knowledge it is more readable then from my point of view
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
anyway i'm not going to stop merging just because of this
I expressed my concerns and leave the final decision up to you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a huge fan of static imports (AssertJ for example), but in this case, importing "of" doesn't really add to readability, so I'd lean towards keeping the classname there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I'm too late it seems :)
| if (log.isLoggable(FINE)) { | ||
| log.fine("Invalid phone: %s".formatted(phoneNumber)); | ||
| } | ||
| errorCount++; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| errorCount++; | |
| errorCount++; | |
| if (allowedErrorsCount > errorCount) { | |
| break; | |
| } |
I guess there is no need to iterate if we already exceed the limit
+ may be similar approach when a number of rest iterations is less than amount of error we still could make and pass the tests... however in this case there will be less log output 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I've added "break" at these places.
Though, this code is temporary anyway. We need to configure phone numbers to achieve 0 error tolerance. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I tried that some time ago, to get close to zero tolerance, but while I managed for some countries, it was non trivial to get them all in shape. Happy if you give it a shot though
I realized that PhoneNumberTest almost didn't test anything: it did 10 iterations, but checked that error count is < 25. :)
Now phone numbers are