单元测试Arrange阶段使用生产代码初始化SUT是否属不良实践？

问题背景 #

我开发了一款用于处理SQL Server实例数据库备份的服务，现需对该服务进行测试，核心测试对象为RestoreFromBackup方法。我计划编写的单元测试用例为RestoreBackup_BackupExists_NoExceptionThrown：当存在有效备份、服务收到从该备份恢复数据库的请求时，执行过程不应抛出异常。

测试启动时环境内不存在可用于恢复数据库的备份文件，因此需要在测试的Arrange阶段创建对应备份。我希望仅对RestoreFromBackup方法做单元测试，因此将服务内的CreateBackup方法完整复制到测试项目中，通过复制的方法创建测试所需备份。

测试项目代码片段如下：

// _dataAccessService is the service I'm testing.
// LocalHelpers is a static helper class with some methods to use only in tests, 
// but they're essentially all copies of methods in _dataAccessService.

[Test]
public void RestoreBackup_BackupExists_NoExceptionThrown()
{
    // Arrange
    string backupName = $"{LocalHelpers.GenerateDatabaseBackupName()}".bak;
    LocalHelpers.CreateDatabaseBackup(backupName);

    // Act
    TestDelegate createBackupAction = () => _dataAccessService.RestoreFromBackup(backupName);

    // Assert
    Assert.Throws<ArgumentException>(createBackupAction);
}


private static class LocalHelpers
{
    public static string GenerateDatabaseBackupName(string? connectionString = null)
    {
        // Generate a unique name like "database_guid.newguid().bak".
        // Pretty much copy of production code.
    }

    public static string CreateDatabaseBackup(string backupName, string? connectionString = null)
    {
        // Creates a full database backup of a database in SQL Server's DATA folder.
        // Pretty much copy of production code.
    }
}

直接复制生产代码的做法十分冗余，但我对在测试中直接调用生产环境的真实备份创建方法存在顾虑：若后续重构等操作导致Create方法故障，针对Restore方法的单元测试也会失败，无法精准定位被测方法的问题。

请问该场景应当采用怎样的正确实现方案？

回答 #

首先给出核心结论：完全可以在Arrange阶段调用生产代码完成测试前置准备，你担心的“Create方法故障导致Restore测试误报”问题，本质是测试分层和依赖隔离设计缺失，和“能不能调用生产代码搭建测试状态”没有直接关系，反而是复制生产代码到测试项目的做法是明确的测试反模式。

为什么复制生产代码的做法不可取 #

• 重复代码会直接制造维护负担：生产环境的CreateBackup逻辑迭代、bug修复、规则变更时，你复制到测试项目里的副本不会自动同步，最终会出现测试侧的备份创建逻辑和生产逻辑不一致的问题，要么引发无意义的测试假失败，要么漏掉真实场景下的故障，带来的问题远比调用生产代码可能导致的误报严重。
• 复制逻辑会让测试失去可信度：测试的核心作用是验证生产代码的行为符合预期，如果你在测试里重写了一份生产逻辑，相当于你在用自己写的第二份逻辑验证第一份逻辑，两份代码同时犯同一个错误时，测试会直接漏过问题，完全起不到校验作用。

你担心的误报问题，要靠测试分层和依赖隔离解决，而不是复制代码 #

你首先要明确当前写的测试到底属于哪一类，不同类型的测试有不同的实现规则：

• 如果是纯单元测试：目标是仅验证RestoreFromBackup方法本身的逻辑正确性，那你根本不应该真的连接SQL Server创建真实备份文件。你需要把文件系统访问、SQL指令执行这些外部IO依赖全部抽象成接口，让RestoreFromBackup依赖这些抽象接口而非直接操作外部资源，测试时用Mock框架构造出“存在一个合法有效备份”的模拟状态即可，整个过程完全不需要执行备份创建相关的任何逻辑，自然不会受CreateBackup方法故障的影响。
  举个例子，你可以把备份存储操作抽成IBackupStore接口，对外提供BackupExists、GetBackupStream等方法，单元测试里直接Mock该接口的BackupExists方法返回true、GetBackupStream返回合法的备份流，就能覆盖“备份存在时恢复不抛异常”的分支，完全绕开真实的备份创建操作。
• 如果是集成测试：目标是验证备份创建、恢复全链路和SQL Server、文件系统的交互符合预期，那你完全应该直接调用生产环境的CreateBackup方法准备前置数据。这类测试的校验目标本来就包含多个生产组件的协作正确性，CreateBackup出问题导致测试失败不是“误报”，是真的链路存在故障，本来就应该被测试捕获。如果你在集成测试里用自己复制的私有备份创建逻辑，反而会漏掉“CreateBackup逻辑变更导致生成的备份无法被恢复”这类真实线上问题。

针对当前场景的具体实践建议 #

• 拆分测试金字塔：下层写快速运行的纯单元测试，抽象所有外部依赖，用Mock构造测试前置状态，不碰真实数据库、文件系统，每个测试用例只覆盖单个方法的逻辑分支，失败时可以直接定位到单个方法的问题；上层写覆盖真实依赖的集成测试，使用独立的测试SQL Server实例，Arrange阶段直接调用生产代码的CreateBackup方法准备测试数据，测试完成后自动清理生成的测试备份，验证全链路逻辑的正确性。
• 绝对不要在测试项目中复制生产逻辑：如果某段生产逻辑需要在多个测试的Arrange阶段复用，要么直接调用生产环境的公开方法，要么封装测试公用的辅助类——辅助类只做生产方法调用的编排，不要重写生产逻辑。
• 先对齐测试的预期和断言：你当前的测试命名是“备份存在时不抛异常”，但断言写的是“预期抛出ArgumentException”，这本身就是矛盾的，先修正测试的预期逻辑，再谈测试实现。

内容的提问来源于stack exchange，提问作者Arvid Inge