Add OccurrenceConstraint extensions for integer?

[siewers]

I was wondering if it would make sense to include an extension method for Exactly.Times like this:

myString.Should().Contain("something", 4.Times()); // Equivalent to Exactly.Times(4)

I think it reads a bit better than the existing Exactly.Times(4), but perhaps this has already been considered?

I understand there might be some confusion around AtLeast, AtMost etc., but that might be fixed like:

myString.Should().Contain("something", 4.TimesOrMore()); // Equivalent to AtLeast.Times(4) and MoreThan(3)
myString.Should().Contain("something", 4.TimesOrLess()); // Equivalent to AtMost.Times(4) and LessThan(5)

There seems to be some redundancy in with AtLeast/MoreThan and AtMost/LessThan, but they might be useful in scenarios I've never had.

I know creating such extensions is pretty straightforward:

public static class FluentOccurrenceConstraintExtensions
{
    public static OccurrenceConstraint Times(this int times)
    {
        return Exactly.Times(times);
    }

    public static OccurrenceConstraint TimesOrLess(this int times)
    {
        return AtLeast.Times(times);
    }

    public static OccurrenceConstraint TimesOrMore(this int times)
    {
        return AtMost.Times(times);
    }
}

[siewers]

You could also create a builder and have properties like Exactly, OrMore, OrLess:

public static class FluentOccurrenceBuilder
{
    public static OccurrenceConstraintBuilder Times(this int times)
    {
        return new OccurrenceConstraintBuilder(times);
    }
}

public sealed class OccurrenceConstraintBuilder
{
    private readonly int _times;

    public OccurrenceConstraintBuilder(int times)
    {
        _times = times;
    }

    public OccurrenceConstraint Exactly => FluentAssertions.Exactly.Times(_times); // Namespace qualification needed to avoid conflict

    public OccurrenceConstraint OrLess => AtMost.Times(_times);

    public OccurrenceConstraint OrMore => AtLeast.Times(_times);
}

This would allow you to write this instead:

4.Times().Exactly;
4.Times().OrLess;
4.Times().OrMore;

[IT-VBFK]

Is it intentional that you are using AtLeast / AtMost for TimesOrLess / TimesOrMore?

I ask, because I think using AtMost for TimesOrMore is not correct. AtMost => x <= times; TimesOrMore implicates x >= times;

[siewers]

It's probably just a typo 🙂

Updated.

[IT-VBFK]

Thx

[dennisdoomen]

I think it's a nice idea and looks a bit better than Exactly.Times(0)

[dennisdoomen]

Wonder what @jnyrup thinks about this.

[jnyrup]

I like the idea, but I think we should only introduce a single other way

[siewers]

@jnyrup I would not like to have multiple ways of doing it either, I'm just not sure which one is better. If only you could have extension properties :)
I don't really like the parenthesis, which is why I thought of the builder, however, that also seems a bit excessive, so perhaps there are other alternatives I didn't think of?

[dennisdoomen]

a single other way

I was referring to the original idea in this discussion, e.g. 4.TimesOrMore()

[jnyrup]

I'm mostly leaning towards 4.Times(), 4.TimesOrMore(), 4.TimesOrLess().
The only thought I have (unless I'm just chasing ghosts) is the slight ambiguity if 4.Times() means exactly or at least 4 times.

[dennisdoomen]

The only thought I have (unless I'm just chasing ghosts) is the slight ambiguity if 4.Times() means exactly or at least 4 times.

If somebody tells me that something should contain something else 4 times, I would have no doubts that this person meant "4 times exactly"

[jnyrup]

Maybe it's just one of those computer science-related injuries?

How about then naming it 4.TimesExactly() to remove all ambiguity?

[siewers]

I wouldn't be in doubt either.

someString.Should().Contain("something", 10.Times());

Reading that line doesn't make me question whether there should be at least ten occurrences or exactly ten occurrences - I know it has to contain the string exactly ten times.

[IT-VBFK]

Is this change still relevant? I think I can give it a shot if @siewers does not mind 🙃

[dennisdoomen]

Yes, I'm totally open to that. I guess it's a feature that isn't very discoverable. How do we make it clear to our users that we have a better way to express occurrences?

[siewers]

@IT-VBFK I already have a local implementation, but feel free to give it a shot. I don't have any problem with that, as long as we agree on the signatures.

@dennisdoomen I'm not sure we'll get any better discoverability than what we already have the other integer extensions. I'm rarely seeing anyone in my team and organization using the extension methods, and I keep telling them to use them 🙂
People are simply not used to or comfortable with implicit conversions.

[IT-VBFK]

as long as we agree on the signatures.

🤔 Authored by @siewers, committed by @IT-VBFK?

[IT-VBFK]

I guess it's a feature that isn't very discoverable

How about "forcing" users to use the new approach by marking the "old" one with obsolete?

[dennisdoomen]

I'm in doubt about that one. A lot of codebases treat warnings as errors.

[IT-VBFK]

Ok, what about [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]?

I think that approach is used somewhere else in FA as I remember correctly.

[jnyrup]

I don't think there's anything wrong in continue using AtLeast.Times(4) over the proposed 4.TimesOrMore().
Similar to how people are free to use 4.Seconds() or TimeSpan.FromSeconds(4).

All current usage of [EditorBrowsable(EditorBrowsableState.Never)] are for redirecting from BeGreaterOrEqualTo to BeGreaterThanOrEqualTo (and Less -> LessThan).

Do you think 4.TimesExactly() over 4.Times() is overly verbose compared the complete elimination of ambiguity?

[siewers]

In case you are using ReSharper, the EditorBrowsable attribute is ignored by default, rendering it's application useless, unless the consumer has configured ReSharper to obey the attribute.

[IT-VBFK]

Done in #2047