S6354: Description for "testable clock" provides no compliant implementation

[lg2de (Lukas Grützmacher)]

The description for S6354 (testable clock) provides a compliant interface:

public interface IClock
{
    DateTime UtcNow();
}

Expected that the implementation of this interface will be compliant:

internal class Clock : IClock
{
    public DateTime UtcNow()
    {
        return DateTime.UtcNow;
    }
}

But S6354 is raised here too.

What must the correct implementation look like?

[ganncamp (G Ann Campbell)]

Hi,

Could you share the product & version you’re seeing this in? (And verify that we’re talking about C# too?) The rules site actually shows multiple compliant solutions, which indicates to me that you may be looking at an old version of the rule description in an out-of-date product version.

 
Ann

[lg2de (Lukas Grützmacher)]

The example is C#.
We are using SQ 9.5.0, SonarAnalyzer 8.40.0.48530 and SonarLint 6.6.0.49766.

[Martin_Strecker]

Hi @lg2de,

The rule does not detect any “compliant production” implementation. It will always raise for any DateTime.UtcNow access. The reasoning is, that we can not detect that the usage of DateTime.UtcNow is compliant in that specific context. But there should be exactly one location in your solution where this issue is a false positive. You should suppress it there with a #pragma warning disable S6354 // Compliant implementation of the clock interface for production.

I created an issue for this and added it to our backlog:

FP S6354: No compliant solution "Use a testable (date) time provider instead."

Best, Martin

[Corniel (Corniel Nobel)]

@Martin_Strecker unfortunately, that is not true. If you use an external implementation of an IClock interface, or a testable clock like this one, you’ll have none.

Furthermore, if you deal with multiple IClock interfaces (once of your project, and one provided by another package, which happened at once in my career), or if (also from own experience) you’ll have might end up with multiple.

So the best you can - and I argue should - do, is use suppress to explain that this occasion is your production implementation that helps you to overcome the problem raised by this rule.