fix: resolve timezone skew and Windows path URL formatting in unit tests#138
Open
tushar2682 wants to merge 1 commit into
Open
fix: resolve timezone skew and Windows path URL formatting in unit tests#138tushar2682 wants to merge 1 commit into
tushar2682 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I ran the unit tests locally and ran into a couple of environment-related failures.
First, a couple of test cases were failing because
Calendar.getInstance()is timezone-dependent. Since my machine is set to a local timezone, the formatted output was off by a few hours compared to the hardcoded UTC timestamps in the assertions. I fixed this by specifying the UTC timezone when initializing the calendars in ThreeDSecureLookupRequestTest and TransactionIndustryRequestTest.Second, TransactionLevelFeeReportTest was throwing an UnknownHostException on Windows. The test was manually prepending "file://" to the absolute path, which results in "file://C:..." on Windows. Java parses the "C:" as a hostname and fails. I changed it to use
.toURI().toURL().toString()which handles the file URL construction cleanly across platforms.Everything passes successfully now when running
mvn test -DskipITs.