Add BeCloseTo() / NotBeCloseTo() to TimeOnlyAssertions - #2030

Pull Request Test Coverage Report for Build 3542928324

Warning: This coverage report may be inaccurate.

We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.004%) to 96.874%

Totals
Change from base Build 3509527656:	0.004%
Covered Lines:	12435
Relevant Lines:	12682

💛 - Coveralls

I can't figure out what kind of test branch coverage thinks we're missing 🤔

Me too 😅

I noticed that while TimeSpan, DateTime and DateTimeOffset are linear in time, TimeOnly is circular like a clock on the wall.
So it does not have overflow like the other, but will wrap around.

This bring the question, is 23:59 is close to 00:01 ±2 minutes?
I found out that TimeOnly.IsBetween exists for this.

This bring the question, is 23:59 is close to 00:01 ±2 minutes?

Hmm.. good catch.. I would say yes.. 🤔

What does @dennisdoomen thinks about that?

I found out that TimeOnly.IsBetween exists for this.

Yes, but this is exclusive the end time. so IsBetween(23:00, 01:00) would fail if the precision includes 01:00. Is that what we want here, because DateTime.BeCloseTo() includes the maximum end date / time. IMHO this behavior should be the same at all assertions.

I could workaround by adding 1 tick to the maximum time.. so this should work.. But looks like a bad hack..

Adding 1 tick was also my idea.
That we're using IsBetween is an implementation detail.

Ok.. this should be easy..

But this does not help to get rid of the min/max calculation.

Changing the code signature to BeCloseTo(startTime, endTime) would face this issue, but I do not like having 2 different signatures for DateTimeand TimeOnly..

Edit: BeCloseTo(startTime, endTime) would definitely not work 🙈

This bring the question, is 23:59 is close to 00:01 ±2 minutes?

Given the behavior of TimeOnly, I think this is fair.

Pull Request Test Coverage Report for Build 3517626725

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 11 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.3%) to 95.928%

Files with Coverage Reduction New Missed Lines %
Src/FluentAssertions/Data/DataEquivalencyAssertionOptions.cs 11 86.73%
Totals
Change from base Build 3504387639: 0.3%
Covered Lines: 8494
Relevant Lines: 8741

💛 - Coveralls

What's the best way to generate random numbers: let coveralls calculate your coverage.. 😂