技术分享｜单元测试推广与实战-在全新的DDD架构上进行单元测试

Posted dotNET跨平台

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了技术分享｜单元测试推广与实战-在全新的DDD架构上进行单元测试相关的知识，希望对你有一定的参考价值。


源宝导读：单元测试是伴随软件工程出现和发展的，怎么做大家可能各有见解。本文介绍了单元测试中的反模式，强调了可测试性的重要性，并以 DDD 架构项目的迭代进程作为示例，演示了单元测试的组织过程，展示了单元测试如何影响架构设计，进而提高交付质量。

一、背景

    为了满足日益增长的业务需求，天际-DevOps平台于近期开始了重构工作。由于重构过程对各业务场景进行了重新定义，开发过程推行基于 DDD 的编程架构，所以是推广和落地单元测试的很好时机。粮草未动，兵马先行，这里先介绍单元测试的定义、必要性，接着是引入 dotnet 单元测试相关的知识，然后以反模式示例演示可测试性概念，最后在全新项目上演示整个迭代周期中单元测试的策略与实现细节，并进行小结。

二、单元测试相关的概念、工具和技巧

2.1、单元测试的定义

    单元测试是指对软件中的最小可测试单元进行检查和验证，是最低级别的测试活动。开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

  • 验证代码与设计相符合；

  • 跟踪需求与设计的实现；

  • 发现设计和需求中存在的缺陷；

  • 发现在编码过程中引入的错误。

2.2、单元测试的必要性

单元测试能在开发阶段发现 BUG，及早暴露，收益高，是交付质量的保证。

  • 来自微软的统计数据显示，bug在单元测试阶段被发现，平均耗时3.25小时，如果漏到系统测试阶段，要花费11.5小时。

  • 85% 的缺陷都在代码设计阶段产生，而发现 bug 的阶段越靠后，耗费成本就越高，指数级别的增高。

2.3、单元测试相关的模式、知识点和工具

Arrange-Act-Assert (AAA) 模式

    AAA（准备、执行、断言）模式是编写待测试方法的单元测试的常用方法。

    一个典型的单元测试用例如下：

[Fact]
public void Add_EmptyString_ReturnsZero()
{
    // Arrange
    var stringCalculator = new StringCalculator();


    // Act
    var actual = stringCalculator.Add("");


    // Assert
    Assert.Equal(0, actual);
}

NSubstitute

    该类库对自身的定位是 A friendly substitute for .NET mocking libraries，作为老牌 mock 库 moq 的替代实现。（mock 离不开动态代理，NSubstitute 依赖 Castle Core，其原理另起篇幅描述。）

// Arrange（准备）：Prepare
var calculator = Substitute.For<ICalculator>();


// Act（执行）：Set a return value
calculator.Add(1, 2).Returns(3);
Assert.AreEqual(3, calculator.Add(1, 2));


// Assert（断言 ）：Check received calls
calculator.Received().Add(1, Arg.Any<int>());
calculator.DidNotReceive().Add(2, 2);

使用InternalsVisible ToAttribute测试内部类

    为了避免暴露大量的实现细节、提高内聚性，开发人员应应减少 public 访问修饰符的使用。但是非公开的类和方法如何进行测试？这就是 InternalsVisible ToAttribute 的作用，我们可以在被测项目的AssemblyInfo.cs 文件中添加定义，该特性接受 assembly 名称作为参数，对其暴露内部可见性。

[assembly: InternalsVisibleTo("XXX.Tests")]

    也可以在被测试目标的项目文件 .csproj 中使用，并支持使用项目的上下文变量作为参数名。

<ItemGroup>
    <AssemblyAttribute Include="System.Runtime.CompilerServices.InternalsVisibleTo">
      <_Parameter1>$(MSBuildProjectName).Tests</_Parameter1>
    </AssemblyAttribute>
  </ItemGroup>

    通过以上两种方式，单元测试项目拥有了对被测试项目中 internal 类和方法的访问能力。

扩展方法的测试

    大多数场景下扩展方法不具备可测试性，efcore 中以 Async 结尾的扩展方法，测试它们需要实现 IDbAsync QueryProvider 接口，步骤繁琐，业务实现中应注意扩展方法的可测试性。

2.4、可测试性

    可测试性的回顾仍然十分有必要，大概上可以归于以下三类。

不确定性/未决行为

// BAD
public class PowerTimer
{
    public String GetMeridiem()
    {
        var time = DateTime.Now;
        if (time.Hour >= 0 && time.Hour < 12)
        {
            return "AM";
        }
        return "PM";
    }
}

依赖于实现：不可 mock

// BAD: 依赖于实现
public class DepartmentService
{
    private CacheManager _cacheManager = new CacheManager();


    public List<Department> GetDepartmentList()
    {
        List<Department> result;
        if (_cacheManager.TryGet("department-list", out result))
        {
            return result;
        }
        // ... do stuff 
    }
}


// BAD: 静态方法
public static bool CheckNodejsInstalled()
{
    return Environment.GetEnvironmentVariable("PATH").Contains("nodejs", StringComparison.OrdinalIgnoreCase);
}

复杂继承/高耦合代码：测试困难

    随着步骤与流程判断增加，场景组合和 mock 工作量成倍堆积，直到不可测试。

三、实战：在全新的 DDD 架构上进行单元测试

    HelloDevCloud 是一个假想的早期 devOps 产品，提供了组织（Organization）和项目（Project）管理，遵从极简的 DDD 架构，预计的项目结构如下：

$ tree -L 2
.
├── doc
├── HelloDevCloud.sln
├── README.md
├── src
│   ├── HelloDevCloud.Domain                领域对象
│   ├── HelloDevCloud.Domain.Shared
│   ├── HelloDevCloud.DomainService         领域服务
│   ├── HelloDevCloud.EntityFrameworkCore   基于 efcore 的仓储模式实现
│   ├── HelloDevCloud.Infrastructure        基础设施
│   ├── HelloDevCloud.Repositories          DbContext 与仓储
│   └── HelloDevCloud.Web                   Web 接口
└── test
    ├── HelloDevCloud.DomainService.Tests   领域服务测试用例
    ├── HelloDevCloud.RepositoriesTests     DbContext 与仓储测试用例
    └── HelloDevCloud.Web.Tests             Web 接口测试用例

    基于 DDD 分层架构不一而足，本示例用作单元测试演示。

    目前已有如下领域划分：

  1. 每个组织（Organization）都可以创建一个或多个项目（Project）；

  2. 提供公共的 GitLab 用于托管代码，每个项目（Project）创建之时有 master 和 develop 分支被创建出来；

  3. 项目（Project）目前支持公共 GitLab，但预备在将来支持私有 GitLab。

3.1、需求-迭代1：分支管理

    本迭代预计引入分支管理功能：

  1. 每个项目（Project，聚合根）都能创建特定类别的分支（Branch，实体），目前支持特性分支（feature）和修复分支（hotfix），分别从 develop 分支和 master 分支签出；

  2. GitLab 有自己的管理入口，分支创建时需要检查项目和分支是否存在；

  3. 分支创建成功后将提交记录（Commit）写入分支。

前期：分析调用时序

前期：设计模块与依赖关系

  • IProjectService：领域服务，依赖IGitlabClient完成业务验证与调用；

  • IProjectRepository：项目（Project，聚合根）仓储，更新聚合根；

  • IBranchRepository：分支（Branch，实体）仓储，检查；

  • IGitlabClient：基础设施。

前期：列举单元测试用例

  • 项目领域服务：

    • 在 GitLab 项目不存在时断言失败：CreateBranch_WhenRemoteProjectNotExist_ShouldFailed()

    • 在 GitLab 分支已经存在时断言失败：CreateBranch_WhenRemoteBranchPresented_ShouldFailed()

    • 创建不支持的特性分支时断言失败：CreateBranch_UseTypeNotSupported_ShouldFailed()

    • 正确创建的分支应包含提交记录（Commit）：CreateBranch_WhenParamValid_ShouldQuoteCommit()

  • 项目应用服务：

    • 在项目（Project）不存在时断言失败：Post_WhenProjectNotExist_ShouldFail()

    • 在项目（Project）不存在时断言失败：Post_WhenProjectNotExist_ShouldFail()

    • 参数合法时返回预期的分支的签出结果：Post_WhenParamValid_ShouldCreateBranch()

中期：业务逻辑实现

  1. 项目（Project ）作为聚合根添加分支（Branch）作为组成。

  2. 我们总是需要在远程与本地项目、分支之前进行检查，它们由领域服务组织。

public async Task<Branch> CreateBranch(Project project, string branchName, BranchType branchType)
{
    var gitProject = await _gitlabClient.Projects.GetAsync(project.Gitlab.Id);
    // 断言远程项目存在
    if (gitProject == null)
    {
        throw new NotImplementedException("project should existed");
    }


    // 断言远程分支不何存在
    var gitBranch = await _gitlabClient.Branches.GetAsync(project.Gitlab.Id, branchName);
    if (gitBranch != null)
    {
        throw new ArgumentOutOfRangeException(nameof(branchName), "remote branch already existed");
    }


    // 获取签出分支
    var reference = GetBranchReferenceForCreate(branchType);
    var request = new CreateBranchRequest(branchName, reference);
    // 创建分支
    gitBranch = await _gitlabClient.Branches.CreateAsync(project.Gitlab.Id, request);


    return project.CheckoutBranch(gitBranch.Name, gitBranch.Commit.Id, branchType);
}


private String GetBranchReferenceForCreate(BranchType branchType)
{
    return branchType switch
    {
            BranchType.Feature => Branch.Develop,
            BranchType.Hotfix => Branch.Master,
            _ => throw new ArgumentOutOfRangeException(nameof(branchType), $"Not supported branchType {branchType}"),
    };
}

中期：单元测试实现

  • 领域服务：测试用例见于项目源码 test/HelloDevCloud.DomainService.Tests /Projects/ProjectServiceTest.cs。

  • 应用服务：测试用例见于项目源码 test/HelloDevCloud.Web.Tests/Controllers /ProjectControllerTest.cs。

实战小结

  1. 单元测试用例体现了业务规则；

  2. 单元测试同架构一样是分层的。

3.2、需求-迭代2：支持外部 GitLab，支持分支搜索

本迭代预期添加以下内容：

  1. 支持使用外部 GitLab 上管理分支；

  2. 并支持使用名称搜索组织下的分支列表。

前期：设计模块与依赖关系

前期：列举单元测试用例

  • 项目领域服务：

  1. 使用外部 GitLab 仓库能签出分支：CreateBranch_UserExternalRepository _ShouldQuoteCommit()；

  • 分支仓储：

    1. 从配置了外部仓库的项目获取分支应返回符合预期的结果：GetAllByOrganization_ ViaName_ReturnMatched

    中期：业务逻辑实现

    1. 使用新的工厂接口 IGitlabClient Factory 替换 IGitlabClient；

    1. 使用组织 Id 查询分支列表。

    public IList<Branch> GetAllByOrganization(int organizationId, string search)
{
    var projects = EfUnitOfWork.DbSet<Project>();
    var branchs = EfUnitOfWork.DbSet<Branch>();
    var query = from b in branchs
                join p in projects
                    on b.ProjectId equals p.Id
                where p.OrganizationId == organizationId && (b.Type == BranchType.Feature || b.Type == BranchType.Hotfix)
                select b;


    if (string.IsNullOrWhiteSpace(search) == false)
    {
        query.Where(x => x.Name.Contains(search));
    }


    return query.ToArray();
}

    中期：单元测试实现

    • 领域服务：测试用例见于项目源码 test/HelloDevCloud.DomainService.Tests/ Projects/ProjectServiceTest.cs；

    • 仓储实现：测试用例见于项目源码 test/HelloDevCloud.RepositoriesTests/ Implements/BranchRepositoryTest.cs。

        注意：仓储仍然是可测且应该进行测试的，mock 数据库查询的主要工作是 mock IQuerable<T>，但是 mock 数据库读写并不容易。好在 efcore 提供了 UseInMemory Database() 模式，无须我们再提供 FackRepository 一类实现。

    [Fact]
public void GetAllByOrganization_ViaName_ReturnMatched()
{
    var options = new DbContextOptionsBuilder<DevCloudContext>()
        .UseInMemoryDatabase("DevCloudContext")
        .Options;
    using var devCloudContext = new DevCloudContext(options);
    devCloudContext.Set<Project>().AddRange(new[] {
        new Project
        {
            Id = 11,
            Name = "成本系统",
            OrganizationId = 1
        },
        new Project
        {
            Id = 12,
            Name = "成本系统合同执行应用",
            OrganizationId = 1
        },
        new Project
        {
            Id = 13,
            Name = "售楼系统",
            OrganizationId = 2
        },
    });


    devCloudContext.Set<Branch>().AddRange(new[] {
        new Branch
        {
            Id = 101,
            Name = "3.0.20.4_core分支",
            ProjectId = 11,
            Type = BranchType.Feature
        },
        new Branch
        {
            Id = 102,
            Name = "3.0.20.1_core发版修复分支15",
            ProjectId = 12,
            Type = BranchType.Hotfix
        },
        new Branch
        {
            Id = 103,
            Name = "730Core自动化验证",
            ProjectId = 13,
            Type = BranchType.Feature
        }
    });
    devCloudContext.SaveChanges();


    var unitOfWork = new EntityFrameworkUnitOfWork(devCloudContext);
    var branchRepo = new BranchRepository(unitOfWork);


    var branches = branchRepo.GetAllByOrganization(1, "core");
    Assert.Equal(2, branches.Count);
    Assert.Equal(101, branches[0].Id);
    Assert.Equal(102, branches[1].Id);
}

    ANTI-PATTERN：依赖具体实现

        支持外部 GitLab 仓库需要动态生成 IGitlabClient 实例，故在业务逻辑中根据项目（Project）设置实例化 GitlabClinet是很“自然”的事情，但代码不再具有可测试性。

        对应的实现逻辑片段如下：

    //BAD
-        private readonly IGitLabClient _gitlabClient;
+        private readonly IOptions<GitlabOptions> _gitlabOptions;


-        public ProjectService(IGitLabClient gitlabClient)
+        public ProjectService(IOptions<GitlabOptions> gitlabOptions)
         {
-            _gitlabClient = gitlabClient;
+            _gitlabOptions = gitlabOptions;
         }
         
         public async Task<Branch> CreateBranch(Project project, string branchName, BranchType branchType)
         {
-            var gitProject = await _gitlabClient.Projects.GetAsync(project.Gitlab.Id);
+            var gitlabClient = GetGitliabClient(project.Gitlab);
+            var gitProject = await gitlabClient.Projects.GetAsync(project.Gitlab.Id);


+        private IGitLabClient GetGitliabClient(GitlabSettings repository)
+        {
+            if (repository?.HostUrl == null)
+            {
+                return GetGitlabClient(_gitlabOptions.Value);
+            }
+
+            // 如果携带了 gitlab 设置, 则作为外部仓库
+            var gitlabOptions = new GitlabOptions()
+            {
+                HostUrl = repository.HostUrl,
+                AuthenticationToken = repository.AuthenticationToken
+            };
+            return GetGitlabClient(gitlabOptions);
+        }
+
+        private IGitLabClient GetGitlabClient(GitlabOptions gitlabOptions)
+        {
+            return new GitLabClient(gitlabOptions.HostUrl, gitlabOptions.AuthenticationToken);
+        }
+    }

        对于以上实现，调用 ProjectService 会真实地调用 GitlabClient，注意这引入了依赖具体实现的反模式，代码失去了可测试性。

    [Fact(Skip = "not implemented")]
public async Task CreateBranch_UserExternalRepository_ShouldQuoteCommit()
{
    var project = new Project
    {
        Gitlab = new GitlabSettings
        {
            Id = 1024,
            HostUrl = "https://gitee.com",
            AuthenticationToken = "token"
        }
    };


    // HOW? 
}

        提问：如果需要取消 develop 分支的特殊性，允许用户自行管理，在方法 GetBranch ReferenceForCreate() 上注释掉分支判断是否完成了需求？

    private String GetBranchReferenceForCreate(BranchType branchType)
{
   return branchType switch
   {
       BranchType.Feature => Branch.Develop,
-      // BranchType.Feature => Branch.Develop,
       BranchType.Hotfix => Branch.Master,
       _ => throw new ArgumentOutOfRangeException(nameof(branchType), $"Not supported branchType {branchType}"),
   };

        可以想象大片的测试用例会挂掉，因为该方法被广泛使用并断言。由于单元测试不再成功，单元测试对业务逻辑的保护也随之消失。如果不修复单元测试，我们就无法保证其他业务不受影响。

    实战小结

    1. 良好的设计具有很好的可测试性，可测试性要求反过来会影响架构设计与领域实现；

    2. 仓储逻辑也能够进行有效的测试；

    3. 单元测试减少了回归工作量，提升了交付质量。

    四、后话

        以迭代紧张为理由在提交业务代码时候忽略单元测试的编写，是项目管理及开发人员对单元测试认识有限的体现。本文描述了定义和必要性，基于 DDD 架构进行了实践，展示了单元测试如何影响业务逻辑甚至是架构设计。

    1. 开发人员应认识和理解单元测试，熟练运用相关工具和技能；

    2. 交付质量保证应在开发阶段就由单元测试覆盖率保证；

    3. 测试先行体现了业务规则，要求逻辑自洽和场景覆盖；

    4. 可测试性要求会倒推架构合理性，避免架构劣化甚至反模式。

    ------ END ------

    作者简介

    冯同学： 研发工程师，目前负责开发云平台相关研发工作。

    也许您还想看：

    技术分享｜To B复杂系统的性能测试要注意哪些？

    ERP平台的自动化测试技术实践

    更多明源云·天际开放平台场景案例与开发小知识，可以关注明源云天际开发者社区公众号：

    建模零代码之建模账号接入DevOps 账号体系

    繁星计划·上海站 迈出企业数字化升级赋能第一步

    建模零代码之业务组件的复用

以上是关于技术分享｜单元测试推广与实战-在全新的DDD架构上进行单元测试的主要内容，如果未能解决你的问题，请参考以下文章

DDD应用架构内部分享

技术周报 · 面向未来与浏览器规范的前端 DDD 架构设计

秒杀系统架构的分析与实战！

收藏秒杀系统架构的分析与实战！

DDD实战进阶第一波(十五)：开发一般业务的大健康行业直销系统（总结篇）

DDD专栏11微服务时代，单体架构淘汰了吗？