-
Notifications
You must be signed in to change notification settings - Fork 0
Implement tests for (when)
option
#160
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
# Conflicts: # java/src/main/kotlin/io/spine/validation/java/InTimeGenerator.kt
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #160 +/- ##
============================================
- Coverage 33.88% 33.82% -0.07%
Complexity 344 344
============================================
Files 137 137
Lines 2718 2723 +5
Branches 230 233 +3
============================================
Hits 921 921
- Misses 1734 1739 +5
Partials 63 63 |
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.
In general, LGTM. However, please see my question(s).
* 1. The generated code uses `io.spine.base.Time.currentTime()` to get the current timestamp | ||
* for comparison. In turn, this method relies on `io.spine.base.Time.SystemTimeProvider` | ||
* by default, which has millisecond precision. | ||
* 2. Adding too small amount of time to make the stamp denote "future" might be unreliable. |
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.
So why don't we choose two days instead?
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.
To be closer to the precision threshold. two days
is already a seconds-based precision. Any value less than 1s would confirm millisecond precision during comparison.
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've bumped to 500ms in case of slow VMs on CI.
* 1. The generated code uses `io.spine.base.Time.currentTime()` to get the current timestamp | ||
* for comparison. In turn, this method relies on `io.spine.base.Time.SystemTimeProvider` | ||
* by default, which has millisecond precision. | ||
* 2. Adding too small amount of time to make the stamp denote "future" might be unreliable. |
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.
Same question as the one above.
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.
Please see my comments.
java-tests/validating/src/test/kotlin/io/spine/test/options/when/ProtoTimestampWhenSpec.kt
Show resolved
Hide resolved
`when given a timestamp denoting` { | ||
|
||
@Nested | ||
inner class `the past` { |
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.
Please have inner class
on the same line with @Nested
.
* There are two reasons for choosing fifty milliseconds: | ||
* | ||
* 1. The generated code uses `io.spine.base.Time.currentTime()` to get the current timestamp | ||
* for comparison. In turn, this method relies on `io.spine.base.Time.SystemTimeProvider` |
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.
Please indent the lines in the numbered items with two spaces. It helps in vertical scanning when reading.
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.
LGTM
During the migration to typed expressions, we discovered an incompatible expression in
InTimeGenerator
. It was fixed in-place. This PR adds missing tests for(when)
option and fixes another bug, which led to generation of validation code for SpineTemporal
when the message declaredrepeated google.protobuf.Timestamp
.Now, there are two similar test suites to cover Protobuf
Timestamp
and SpineTemporal
(particularlyio.spine.time.LocalDateTime
). Repeated fields have also been covered.