Unit testable code

Hi folks, I would be interested in getting to know your opinion about making the library work in unit tests. Is there something I miss, or is it currently impossible to write unit tests for code that uses the library? E.g. I have my consuming code

   public class MetricLogger 
   {
        private static Counter _methodCallCounter = Prometheus.Metrics.CreateCounter(
            "ServiceName_call_count",
            "counter of calls", 
            new []{"method"});

        public void OnCalled(string key)
        {
            try
            {
                _methodCounter.Labels(key).Inc();
            }
            catch (Exception exc)
            {
                _logger.LogError(default, exc, "Could not log metric.");
            }
        }
  }

And now I want to unit test if the counter has been created and the Inc method has been called. There is no way to access the counters in the registry. Everything is hardwired to real implementations.

The solution here would be quite simple:

• to give the CollectorRegistry an interface ICollectorRegistry
• expose the registered Collector’s in the new ICollectorRegistry
• allow MetricFactory to accept ICollectorRegistry instead of CollectorRegistry
• to give the MetricFactory an interface IMetricFactory
• extend Metrics with an option to set _defaultFactory from outside (eg. SetMetricFactoryForTests)

That would even enable me to remove the call to the static Metrics class in my consuming code and pass in a mockable IMetricFactory as constructor dependency.

If you think that makes sense, I could try to make PR. Regards, jbrekle

[janjuza]

HI, I would like to mock Counter class, nothing above is straightforward. I would like to test methods WithLabels() and Inc(), but they are not even in the same interface. Would it be possible replace result type Counter by some interface which would implement all other interfaces, to allow mock any method from all Counter’s interfaces? I think this could be ultimate solution for all mocking problems.

[DanielBryars]

Yeah the above isn’t going well for me, instead I’ve just made an IMetricsFactoryFactory, this means that in my libraries I don’t take a dependency on how the MetricsFactory is instantiated, but I do take a dependency on the concretes - which is fine:

`public class MetricFactoryFactory : IMetricFactoryFactory { private readonly CollectorRegistry _registry; private MetricFactory _metricFactory;

    public MetricFactoryFactory()
    {
        _registry = new CollectorRegistry();
        DotNetStats.Register(_registry);
        _metricFactory = Metrics.WithCustomRegistry(_registry);
    }

    public MetricFactory Create()
    {
        return _metricFactory;
    }
}`

MetricFactoryFactory : IMetricFactoryFactory is registered as a singleton in the DI by the process which consumes the library, and in tests you can make a custom registry if you want.