我们对大部分业务逻辑进行单元测试,但仍停留在如何最好地测试我们的一些大型服务任务和导入/导出例程上。例如,考虑将工资单数据从一个系统导出到第 3 方系统。为了以公司需要的格式导出数据,我们需要访问大约 40 个表,这为创建测试数据和模拟依赖关系创造了一个噩梦。
例如,考虑以下内容(约 3500 行导出代码的子集):
public void ExportPaychecks()
{
var pays = _pays.GetPaysForCurrentDate();
foreach (PayObject pay in pays)
{
WriteHeaderRow(pay);
if (pay.IsFirstCheck)
{
WriteDetailRowType1(pay);
}
}
}
private void WriteHeaderRow(PayObject pay)
{
//do lots more stuff
}
private void WriteDetailRowType1(PayObject pay)
{
//do lots more stuff
}
我们在这个特定的导出类中只有一个公共方法——ExportPaychecks()。对于调用此类的人来说,这确实是唯一有意义的操作……其他一切都是私有的(约 80 个私有函数)。我们可以将它们公开以进行测试,但随后我们需要模拟它们以分别测试每一个(即,如果不模拟 WriteHeaderRow 函数,您将无法在真空中测试 ExportPaychecks。这也是一个巨大的痛苦。
由于这是一个单一的导出,对于单一供应商来说,将逻辑移入域是没有意义的。该逻辑在这个特定类之外没有领域意义。作为测试,我们构建了具有接近 100% 代码覆盖率的单元测试……但这需要输入到存根/模拟对象中的大量测试数据,加上由于存根/模拟我们的许多依赖项而产生的超过 7000 行代码.
作为 HRIS 软件的制造商,我们有数百个出口和进口。其他公司真的对这类事情进行单元测试吗?如果是这样,有什么捷径可以减轻痛苦吗?我很想说“没有对导入/导出例程进行单元测试”,稍后再实施集成测试。
更新- 感谢所有的答案。我很想看到一个例子,因为我仍然没有看到有人如何将大文件导出之类的东西变成易于测试的代码块,而不会使代码变得一团糟。