search

naoty / Timepiece

Intuitive date handling in Swift
MIT License
2.63k stars 147 forks source link

Restored a testcase that was deleted by accident #12

Closed mattijsf closed 9 years ago

mattijsf commented 9 years ago

Restored a testcase that was deleted by accident in compare-duration branch

mattijsf commented 9 years ago

Interesting ✗ testAgo, XCTAssertEqualWithAccuracy failed: ("1431707535.45406") is not equal to ("1431707534.88636") +/- ("0.01") -

It runs fine repeatedly on my system. Maybe due to the somewhat slow performance of travis-ci it takes a while between loading the DurationTestCase class and executing the testAgo() testLater(). And the above case it is even ~500ms.

I suggest to inline the let duration = Duration(value: 1, unit: .CalendarUnitDay) statement in each test case to rule that out.

naoty commented 9 years ago

Circle CI can be ignored. I forgot to disable it. But, the build error of travis cannot be ignored. It seems that a test with XCTAssertEqualWithAccuracy is failed. As you said, the result of this assertion depends on the system. So, this should not be used as possible. But, if you have no way other than this, now property should be defined and used for all date calculations.

mattijsf commented 9 years ago

I updated Duration to allow both duration.later and also duration.later(someDate). See a12e4c2386bbe246c12a147642c616093bf6b9c6.

Basically the property duration.later is the same is calling the function duration.later(NSDate()). This addition makes the later and the ago feature even more useful in my opinion. And it should fix the test case :)

It is either this or increase the accuracy of XCTAssertEqualWithAccuracy to ~1000ms I guess.

naoty commented 9 years ago

The addition is useful! But, duration.later(from: date) is more intuitive and Swift-like.

mattijsf commented 9 years ago

I agree. I've included the proposed parameter.

naoty commented 9 years ago

@mattijsf Thank you for the good work!

naoty commented 9 years ago

Released your works at 0.3.2.