如果我正在测试与错误相关的内容,我可能希望最初在控制台中看到消息或堆栈跟踪。在我对测试感到满意后,我通常不希望控制台上堆满任何可能有助于快速发现和诊断测试失败的内容。但是,在进行重构时,再次输出其他信息有时很有用。所以我有很多分散的内容,我评论/取消评论,如:
// System.Diagnostics.Debug.WriteLine(msg);
更简洁的方法是什么?
干杯,
Berryl
===编辑
以下是我的意思的一个示例,根据Josh的建议更新为使用Log服务。
作为单元测试,我想断言将向用户显示错误,在这种情况下,因为新部门的名称重复。我可以并且确实使用正确的内容自动生成消息。
该消息还必须通过一个无法自动化的基本气味测试 - 它是一个结构良好的句子,大多数用户会很快理解并知道如何修复?我不想要启动ui并让用户确保它不是完全愚蠢的,所以我想通过将其打印出来来吸引眼球。正如我之前提到的那样,除了消息改变的次数之外,这只是噪音。
[Test]
public void WhenThePropertyIsChanged_IfDuplicateIsFound_DuplicateNameIsPartOfBrokenRuleMessage()
{
const string newName = "Blah";
// force a duplicate
_dao.Stub(x => x.FindByName(newName)).Return(new Department(newName));
var vm = _masterVm.Departments.Last();
vm.Name = newName;
var msg = vm.GetBrokenRules().First().Description;
Log.Service.WriteLine(msg); <=== print it
Assert.That(msg, Is.StringContaining(newName));
Assert.That(vm.BrokenRules.First().Description, Is.EqualTo(msg));
}
答案 0 :(得分:2)
将日志记录语句包装到服务中并将代码包装到接口。
public interface ILoggingService
{
void WriteLine(String msg);
}
创建一个允许访问日志服务的静态类,但允许您设置服务。
internal static class Log
{
private static ILoggingService _loggingService;
internal static ILoggingService Service
{
get{ return _loggingService ?? (_loggingService = new DefaultLoggingService()); }
set{ _loggingService = value; }
}
}
现在,您只需在写入调试流的测试中实现服务。
public class DebugLoggingService: ILoggingService
{
public void WriteLine(String msg)
{
System.Diagnostics.Debug.WriteLine(msg);
}
}
Log.Service = new DebugLoggingService();
您的代码现在可以保持不变,您只需通过注释掉那里的行来更改您的DebugLoggingService。或者更好的是,您可以将其包装在#if DEBUG ... #endif
语句中。
答案 1 :(得分:1)
最好使用控制台输出的断言。如果计算机可以显示它,它也可以验证它,比你快得多。
如果您没有真正的单元测试,并且正在手动测试,则可以使用Log4,这样您就可以轻松调整所需的跟踪级别。