尧图网站建设 
如何用 Stryker.NET 对 Modular Monolith with DDD 领域模型做变异测试并分析存活变异体【免费下载链接】modular-monolith-with-dddFull Modular Monolith application with Domain-Driven Design approach.项目地址: https://gitcode.com/GitHub_Trending/mo/modular-monolith-with-dddmodular-monolith-with-ddd 是一个 .NET 8.0 实现的 Full Modular Monolith 应用每个模块的 Domain Model 采用 DDD 战术模式实现业务规则通过CheckRule和业务规则类保护。单元测试覆盖这些规则后还有一个问题需要验证现有测试是否真的足够充分还是只覆盖了代码而没有检查到具体需求。本文以仓库文档中的 Stryker.NET 变异测试章节 为准用 Stryker.NET 对 Meetings 模块的领域模型单元测试做变异测试并分析一个真实的存活变异体说明如何通过变异报告判断测试缺口。先明确变异测试的判定逻辑变异测试用来评估现有测试的充分性而不是测试代码本身的功能。框架会对代码做局部修改称为mutation或mutant然后运行现有测试如果某个变异导致至少一个测试失败该变异体被杀死killed说明测试能捕捉到这个错误如果某个变异没有让任何测试失败该变异体存活survived说明现有测试对这段行为不充分。这个判定标准来自 README 3.20 节的原文描述If a given mutation does not cause a failure of at least one test, it means that the mutant has survived so our tests are probably not sufficient.准备条件按 README 的说明需要满足两个前提安装 .NET 8.0 SDK。这是整个项目的运行平台Technology 一节列出的第一项变异测试依赖它来编译代码和运行测试。安装 Stryker.NET。README 将 Stryker.NET 列为项目使用的 Mutation Testing framework并说明其最简用法是安装后进入想要变异测试的测试目录运行dotnet stryker。选择测试目录本仓库中 Meetings 模块的领域模型单元测试位于 src/Modules/Meetings/Tests/UnitTests对应项目文件 CompanyName.MyMeetings.Modules.Meetings.Domain.UnitTests.csproj。该目录包含MeetingTests.cs、MeetingAddNotAttendeeTests.cs、MeetingWaitlistTests.cs等针对Meeting聚合的测试类。README 给出的示例报告正是针对 Meetings 模块单元测试生成的所以本文的主路径也用这个模块。执行变异测试进入上述单元测试目录后运行 README 3.20 节给出的唯一命令dotnet stryker这条命令会在测试所在目录执行Stryker.NET 修改被测代码中的片段并反复运行测试。README 说明该命令的产物是mutation report file变异报告文件后续所有分析都基于这份报告。仓库中保留了一份 Meetings 模块单元测试的示例报告可以直接打开查看无需自行生成docs/mutation-tests-reports/mutation-report.html。README 中展示了这份报告首页的截图文档示例实际运行结果会随测试变化在报告中定位存活变异体打开报告后关注标记为存活survived的变异体条目。每一条存活记录对应一处代码被修改后、所有测试仍然通过的位置也就是测试缺口最可能存在的地方。报告中的变异体条目会指出被修改的代码文件与方法把它与领域模型源码对照即可理解该变异改变了什么行为。案例分析Meeting.AddNotAttendee中的排序变异README 3.20 节挑选了一个报告中的存活变异体作为分析对象完整还原了从报告条目到结论的推理过程。被变异的方法。Meeting.cs 中的AddNotAttendee方法负责把一个Member加入不参加名单。其业务逻辑是如果该成员此前是参会者、后来改主意不参加并且等待名单Waitlist上有人则应把等待名单上的人补进参会者。按需求补进来的应是等待名单上最早报名的人按SignUpDate判断。对应源码中的排序逻辑var nextWaitlistMember _waitlistMembers .Where(x x.IsActive()) .OrderBy(x x.SignUpDate) .FirstOrDefault();变异内容。Stryker.NET 把 LINQ 查询中的排序从默认升序改成了降序即取到的变成了等待名单上最晚报名的人。测试结果。所有现有测试仍然通过没有任何一个测试因为排序反转而失败。结论。这个变异体存活说明测试中不存在校验按SignUpDate排序取最早报名者这一需求的用例。README 由此进一步指出一个更重要的现象代码覆盖不足以下结论——这段代码明明被测试覆盖了覆盖率高但测试并没有检查该需求对应的具体行为代码中此类错误因此无法被发现。变异测试能检测的正是这种覆盖了代码、没检查需求的情况。判定限制与适用边界存活变异体不等于生产 bug。README 明确提醒要谨慎使用该工具as with any tool, we should use it wisely, as not every case requires our attention——并非每个存活变异体都值得处理需要结合该处逻辑的业务重要性自行取舍。仓库中的示例报告mutation-report.html对应 Meetings 模块的单元测试。要对其他模块Administration、Payments、Registrations、UserAccess的领域模型做同样的分析README 给出的方式是安装 Stryker.NET 后进入该模块对应的测试目录运行dotnet stryker报告生成后按同样的定位存活变异体 → 对照源码判断是否漏测流程分析。本文的分析路径以 README 3.20 节的文档为准报告中的具体存活/杀死数量会随测试代码变化不应把仓库示例报告中的数值当作固定预期。【免费下载链接】modular-monolith-with-dddFull Modular Monolith application with Domain-Driven Design approach.项目地址: https://gitcode.com/GitHub_Trending/mo/modular-monolith-with-ddd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何用 Stryker.NET 对 Modular Monolith with DDD 领域模型做变异测试并分析存活变异体
如何用 Stryker.NET 对 Modular Monolith with DDD 领域模型做变异测试并分析存活变异体【免费下载链接】modular-monolith-with-dddFull Modular Monolith application with Domain-Driven Design approach.项目地址: https://gitcode.com/GitHub_Trending/mo/modular-monolith-with-dddmodular-monolith-with-ddd 是一个 .NET 8.0 实现的 Full Modular Monolith 应用每个模块的 Domain Model 采用 DDD 战术模式实现业务规则通过CheckRule和业务规则类保护。单元测试覆盖这些规则后还有一个问题需要验证现有测试是否真的足够充分还是只覆盖了代码而没有检查到具体需求。本文以仓库文档中的 Stryker.NET 变异测试章节 为准用 Stryker.NET 对 Meetings 模块的领域模型单元测试做变异测试并分析一个真实的存活变异体说明如何通过变异报告判断测试缺口。先明确变异测试的判定逻辑变异测试用来评估现有测试的充分性而不是测试代码本身的功能。框架会对代码做局部修改称为mutation或mutant然后运行现有测试如果某个变异导致至少一个测试失败该变异体被杀死killed说明测试能捕捉到这个错误如果某个变异没有让任何测试失败该变异体存活survived说明现有测试对这段行为不充分。这个判定标准来自 README 3.20 节的原文描述If a given mutation does not cause a failure of at least one test, it means that the mutant has survived so our tests are probably not sufficient.准备条件按 README 的说明需要满足两个前提安装 .NET 8.0 SDK。这是整个项目的运行平台Technology 一节列出的第一项变异测试依赖它来编译代码和运行测试。安装 Stryker.NET。README 将 Stryker.NET 列为项目使用的 Mutation Testing framework并说明其最简用法是安装后进入想要变异测试的测试目录运行dotnet stryker。选择测试目录本仓库中 Meetings 模块的领域模型单元测试位于 src/Modules/Meetings/Tests/UnitTests对应项目文件 CompanyName.MyMeetings.Modules.Meetings.Domain.UnitTests.csproj。该目录包含MeetingTests.cs、MeetingAddNotAttendeeTests.cs、MeetingWaitlistTests.cs等针对Meeting聚合的测试类。README 给出的示例报告正是针对 Meetings 模块单元测试生成的所以本文的主路径也用这个模块。执行变异测试进入上述单元测试目录后运行 README 3.20 节给出的唯一命令dotnet stryker这条命令会在测试所在目录执行Stryker.NET 修改被测代码中的片段并反复运行测试。README 说明该命令的产物是mutation report file变异报告文件后续所有分析都基于这份报告。仓库中保留了一份 Meetings 模块单元测试的示例报告可以直接打开查看无需自行生成docs/mutation-tests-reports/mutation-report.html。README 中展示了这份报告首页的截图文档示例实际运行结果会随测试变化在报告中定位存活变异体打开报告后关注标记为存活survived的变异体条目。每一条存活记录对应一处代码被修改后、所有测试仍然通过的位置也就是测试缺口最可能存在的地方。报告中的变异体条目会指出被修改的代码文件与方法把它与领域模型源码对照即可理解该变异改变了什么行为。案例分析Meeting.AddNotAttendee中的排序变异README 3.20 节挑选了一个报告中的存活变异体作为分析对象完整还原了从报告条目到结论的推理过程。被变异的方法。Meeting.cs 中的AddNotAttendee方法负责把一个Member加入不参加名单。其业务逻辑是如果该成员此前是参会者、后来改主意不参加并且等待名单Waitlist上有人则应把等待名单上的人补进参会者。按需求补进来的应是等待名单上最早报名的人按SignUpDate判断。对应源码中的排序逻辑var nextWaitlistMember _waitlistMembers .Where(x x.IsActive()) .OrderBy(x x.SignUpDate) .FirstOrDefault();变异内容。Stryker.NET 把 LINQ 查询中的排序从默认升序改成了降序即取到的变成了等待名单上最晚报名的人。测试结果。所有现有测试仍然通过没有任何一个测试因为排序反转而失败。结论。这个变异体存活说明测试中不存在校验按SignUpDate排序取最早报名者这一需求的用例。README 由此进一步指出一个更重要的现象代码覆盖不足以下结论——这段代码明明被测试覆盖了覆盖率高但测试并没有检查该需求对应的具体行为代码中此类错误因此无法被发现。变异测试能检测的正是这种覆盖了代码、没检查需求的情况。判定限制与适用边界存活变异体不等于生产 bug。README 明确提醒要谨慎使用该工具as with any tool, we should use it wisely, as not every case requires our attention——并非每个存活变异体都值得处理需要结合该处逻辑的业务重要性自行取舍。仓库中的示例报告mutation-report.html对应 Meetings 模块的单元测试。要对其他模块Administration、Payments、Registrations、UserAccess的领域模型做同样的分析README 给出的方式是安装 Stryker.NET 后进入该模块对应的测试目录运行dotnet stryker报告生成后按同样的定位存活变异体 → 对照源码判断是否漏测流程分析。本文的分析路径以 README 3.20 节的文档为准报告中的具体存活/杀死数量会随测试代码变化不应把仓库示例报告中的数值当作固定预期。【免费下载链接】modular-monolith-with-dddFull Modular Monolith application with Domain-Driven Design approach.项目地址: https://gitcode.com/GitHub_Trending/mo/modular-monolith-with-ddd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考