Add timezone function tests #553
Conversation
This will ease customization of timezone-guessing as it is now gets easier to extend that process with own implementations (as long as they implement the appropriate interface) This is espechially necessary when wanting to actually guess a timezone via the rules defined in the VTIMEZONE-entry (which is currently not done)
Codecov Report
@@ Coverage Diff @@
## master #553 +/- ##
============================================
- Coverage 98.69% 98.47% -0.23%
- Complexity 1818 1848 +30
============================================
Files 66 71 +5
Lines 4454 4521 +67
============================================
+ Hits 4396 4452 +56
- Misses 58 69 +11
Continue to review full report at Codecov.
|
|
@staabm @heiglandreas Opinion please! |
|
hmm |
That's the challenge of these simple functions! If someone changes it some day and breaks it (in a way that throws an exception, or they rename or delete the function) then the test will fail. So it protects against obvious "regressions" like that. I'm not sure how to really do better than that, without creating some new example guesser and using it... |
|
I would tackle this problem not on a per method basis, but with a BC check which covers the whole codebase/project regarding BC, e.g. https://github.com/Roave/BackwardCompatibilityCheck |
|
I added The other tests are not that useful. |
This adds test cases for
addTimezoneGuesserandaddTimezoneFinderon top of #548I just tests that the functions can be called without throwing an exception! That at least verifies that the functions still exist and can be called with the tested parameters.
There is not
getTimezoneGuessers()function, so it is not immediately easy to know if the add function did anything. To fully test we would have to provide some new-and-different guesser(s), add it, then do some calls tofindTimeZoneand observe a difference in behavior. I'm not sure how much of that we should try and do.But I am also not sure if these "mindless" test scenarios are worth having.