3 ms·
If I'm parsing the article correctly (And I'm not sure I am), the test was written to care about the current day, because the code under test defaulted to the c
by ergothus 11y ago
If I'm parsing the article correctly (And I'm not sure I am), the test was written to care about the current day, because the code under test defaulted to the current day when no day was specified.
Someone please tell me what "should" have been done. While I recognize that unrepeatable tests can be bad, I don't see how one can test that defaulting code works correctly without messing with whatever that defaulting code relies on (in this case, the system date). I'd think I'd prefer to have some conditional logic in the test than screw with the system clock.
Then again, enough doesn't make sense here (why was this test failing?) that I'm probably misunderstanding the basis.
- edejong 11y agoOur systems generally rely on a (dependency injected) 'currentDateTimeService'. In unit-tests, the currentDateTimeService is dependency-injected with a mock service, always returning the same date. But here, I guess the better solution would be to fix the tested code: don't gracefully fall-back, but fail fast. I've seen too many places where graceful defaulting code ended up corrupting important data.
- UK-AL 11y agoYou usually just mock the date provider, so it just returns the same date every time.
- jdmichal 11y agoIf I have an operation that is dependent on "now", I typically generate that time at the beginning of the operation and pass it as a parameter to everything else. So now all the important bits I can test with whatever timestamp I want. And if I really want to, I could test that the operation initialization generates the correct timestamp. But that's pretty close to testing whether "new Date()" works, which if it doesn't there's not a whole lot I can do about it anyway.