在使用LibLog时,是否可以断言对记录器的调用?假设wiki列出了下面的用法示例:
public class MyClass
{
private static readonly ILog Logger = LogProvider.For<MyClass>();
}在这里,记录器是对使用者隐藏的实现细节,这是使用此库的最大好处。这样,库使用者就不必担心记录器是如何实例化的。看看这篇博文:
http://dhickey.ie/2015/06/capturing-log-output-in-tests-with-xunit2/
似乎添加了很多样板来捕获日志输出,我不完全确定这种方法,因为它在单元测试中也使用了重定向的Serilog输出,这似乎很奇怪,因为库应该只依赖于日志抽象?
我目前能想到的唯一选择是:
注入记录器-这对于库的消费者来说可能有些奇怪,然后每个库都会携带自己需要注入的ILogger定义,这就失去了抽象的优势。
连接到一个真正的日志框架-为LibLog设置当前的LogProvider以使用Log4Net或类似的,然后尝试以某种方式将模拟/存根记录器注入到Log4Net中,并通过代理断言调用。
任何相对简单的方法来断言对记录器的调用都会很受欢迎,但我怀疑并行测试执行会导致问题,即使可以在上面的记录器上断言调用?
发布于 2016-09-15 23:05:20
我在我的项目中做了什么:
我已经创建了我的LoggerFactory。它公开了与NLogger相同的静态方法。
public class LoggerFactory
{
private static ILoggerFactoryStrategy _loggerFactoryStrategy = new DummyLoggerFactoryStrategy();
public static void Initialize(ILoggerFactoryStrategy loggerFactoryStrategy)
{
_loggerFactoryStrategy = loggerFactoryStrategy;
}
public ILogger GetLogger<T>()
{
return _loggerFactoryStrategy.GetLogger<T>();
}
....
}虚拟策略可以只写来调试输出,也可以什么都不做。另一种策略可能看起来像这样:
public class LoggerFactoryStrategy : ILoggerFactoryStrategy
{
public ILogger GetLogger<T>()
{
//create LibLog instance instead with LogProvider.For<T>()
var nlogger = LogManager.GetLogger(typeof(T).Name); //create instance of NLogger
return new NLogLogger(nlogger);
}
}而NlogLogger包装器可以像这样
internal class NLogLogger : ILogger
{
private readonly Logger _logger;
public NLogLogger(Logger logger)
{
_logger = logger;
}
public void Debug(string message)
{
_logger.Debug(message);
}
public void Warn(string message, params object[] args)
{
_logger.Warn(message, args);
}
public void Info(Exception exception)
{
_logger.Info(exception);
}
......
}当应用程序启动时,我使用适当的策略对其进行初始化,在幕后使用NLogger。
如果我想测试对logger的调用,我可以使用mocked策略。此方法允许您在整个解决方案中删除对记录器库的引用(根项目除外),并允许您在将来需要时从一个记录器库切换到另一个记录器库。
此外,这也允许我们在PCL项目中使用NLogger。
发布于 2016-09-20 04:23:37
在几乎所有记录器的日志配置中,您都可以配置在日志失败时抛出异常。
来自nlog的示例
<nlog throwExceptions="true">
... your nlog config
</nlog>但是在LibLog创建的抽象中,您失去了这个特性
https://stackoverflow.com/questions/39272937
复制相似问题