Fixed so that timing will always use native Date for rare cases #240
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.
Since the user might mock Dates in tests, KarmaReporter saves a reference to the native Date and uses that reference for measuring duration. The problem is that it only works when users follows best practises when writing tests.
If a user writes a "bad" test where the Date is mocked in the body of a
decribe
instead of inside anit
orbeforeEach
, the Date is already mocked by the time KarmaReporter is called.By saving the reference at the time adapter.js is executed instead of when KarmaReporter is called, this problem is prevented.
Nothing prevents a developer from writing:
Before the change in this PR, a test like the one above would cause the duration of the test to be reported incorrectly. If the time is reported as negative, then all sorts of thouble can happen down the line.
We ran into issues where a report file generated by karma-sonarqube-unit-reporter containing 4500+ tests was ignored by Sonarqube because a duration in the xml was negative.