ASP.NET Core 试题 44：单元测试与可测试设计
0861 在 控制器单元测试 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 直接 new Controller 会自动运行 ApiController 的自动 400
- B. 模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖
- C. 观察到“无效模型在单元测试中仍进入 Action”即可把一次现象当成完整框架契约。
- D. 控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型
查看答案与解析
正确答案D
正确答案直接描述 控制器单元测试 的主规则：控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型。选项“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”是使用规则时要验证的边界，不是规则本身；“直接 new Controller 会自动运行 ApiController 的自动 400”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0862 无效模型在单元测试中仍进入 Action。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“直接 new Controller 会自动运行 ApiController 的自动 400”定性，不再检查配置、身份或运行时证据。
- B. 先验证“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”，再依据“控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”。
- D. 以一次成功请求作为结论，不再确认“控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型”是否成立。
查看答案与解析
正确答案B
场景“无效模型在单元测试中仍进入 Action”指向 控制器单元测试，但症状本身不能证明根因。正确排查应先确认边界“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”，再用主规则“控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型”解释证据。直接采用误区“直接 new Controller 会自动运行 ApiController 的自动 400”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0863 关于 控制器单元测试，以下哪项说法不成立？
难度： 实战
- A. 直接 new Controller 会自动运行 ApiController 的自动 400
- B. 控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型
- C. 模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖
- D. 出现“无效模型在单元测试中仍进入 Action”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“直接 new Controller 会自动运行 ApiController 的自动 400”正是 控制器单元测试 的典型误区。其余三项分别给出了主规则“控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型”、适用边界“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0864 针对“无效模型在单元测试中仍进入 Action”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“直接 new Controller 会自动运行 ApiController 的自动 400”修改实现，并把一次请求成功作为验收结果。
- B. 按“控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型”修改代码后直接上线，不验证“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”。
- C. 按“控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型”修正实现，并用测试或遥测验证“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”。
- D. 只验证“模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖”，但实现仍继续依赖“直接 new Controller 会自动运行 ApiController 的自动 400”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：控制器测试应聚焦 Action 根据应用服务结果选择的 HTTP 结果和模型；并确认 模型绑定、过滤器和中间件不在直接方法调用中执行，这些需集成测试覆盖。继续接受“直接 new Controller 会自动运行 ApiController 的自动 400”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“无效模型在单元测试中仍进入 Action”这一生产场景能否安全上线。
0865 在 Minimal API 逻辑测试 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射
- B. 把所有逻辑留在内联 Lambda 最容易隔离测试
- C. 只测服务不能覆盖路由绑定和序列化，仍需少量集成测试
- D. 观察到“测试必须启动完整服务器才能验证每个分支”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 Minimal API 逻辑测试 的主规则：复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射。选项“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”是使用规则时要验证的边界，不是规则本身；“把所有逻辑留在内联 Lambda 最容易隔离测试”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0866 测试必须启动完整服务器才能验证每个分支。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“把所有逻辑留在内联 Lambda 最容易隔离测试”定性，不再检查配置、身份或运行时证据。
- B. 先验证“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”，再依据“复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”。
- D. 以一次成功请求作为结论，不再确认“复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射”是否成立。
查看答案与解析
正确答案B
场景“测试必须启动完整服务器才能验证每个分支”指向 Minimal API 逻辑测试，但症状本身不能证明根因。正确排查应先确认边界“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”，再用主规则“复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射”解释证据。直接采用误区“把所有逻辑留在内联 Lambda 最容易隔离测试”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0867 关于 Minimal API 逻辑测试，以下哪项说法不成立？
难度： 实战
- A. 复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射
- B. 只测服务不能覆盖路由绑定和序列化，仍需少量集成测试
- C. 出现“测试必须启动完整服务器才能验证每个分支”时，应收集证据并同时核对主规则与适用边界。
- D. 把所有逻辑留在内联 Lambda 最容易隔离测试
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“把所有逻辑留在内联 Lambda 最容易隔离测试”正是 Minimal API 逻辑测试 的典型误区。其余三项分别给出了主规则“复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射”、适用边界“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0868 针对“测试必须启动完整服务器才能验证每个分支”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把所有逻辑留在内联 Lambda 最容易隔离测试”修改实现，并把一次请求成功作为验收结果。
- B. 按“复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射”修改代码后直接上线，不验证“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”。
- C. 按“复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射”修正实现，并用测试或遥测验证“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”。
- D. 只验证“只测服务不能覆盖路由绑定和序列化，仍需少量集成测试”，但实现仍继续依赖“把所有逻辑留在内联 Lambda 最容易隔离测试”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：复杂处理程序应把业务逻辑提取到服务或可直接调用函数，端点保留绑定与结果映射；并确认 只测服务不能覆盖路由绑定和序列化，仍需少量集成测试。继续接受“把所有逻辑留在内联 Lambda 最容易隔离测试”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“测试必须启动完整服务器才能验证每个分支”这一生产场景能否安全上线。
0869 在 Mock 边界 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL
- B. Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节
- C. 对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表
- D. 观察到“生产查询因不支持的翻译失败”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 Mock 边界 的主规则：Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节。选项“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”是使用规则时要验证的边界，不是规则本身；“Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0870 生产查询因不支持的翻译失败。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”，再依据“Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节”判断实现是否符合契约。
- B. 直接按“Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”。
- D. 以一次成功请求作为结论，不再确认“Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节”是否成立。
查看答案与解析
正确答案A
场景“生产查询因不支持的翻译失败”指向 Mock 边界，但症状本身不能证明根因。正确排查应先确认边界“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”，再用主规则“Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节”解释证据。直接采用误区“Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0871 关于 Mock 边界，以下哪项说法不成立？
难度： 实战
- A. Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节
- B. 对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表
- C. Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL
- D. 出现“生产查询因不支持的翻译失败”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL”正是 Mock 边界 的典型误区。其余三项分别给出了主规则“Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节”、适用边界“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0872 针对“生产查询因不支持的翻译失败”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL”修改实现，并把一次请求成功作为验收结果。
- B. 按“Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节”修改代码后直接上线，不验证“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”。
- C. 只验证“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”，但实现仍继续依赖“Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL”。
- D. 按“Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节”修正实现，并用测试或遥测验证“对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：Mock 适合可控外部边界，不宜复制 EF 查询、框架路由等复杂实现细节；并确认 对真实语义重要的数据库查询应使用目标数据库集成测试，而非只用内存列表。继续接受“Mock 返回预设结果就能证明 LINQ 可翻译成目标 SQL”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“生产查询因不支持的翻译失败”这一生产场景能否安全上线。
0873 在 取消与异常测试 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 未 await 的 Task 失败会稳定让当前测试立即失败
- B. 异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射
- C. 不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态
- D. 观察到“测试显示通过但后台 Task 稍后抛异常”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 取消与异常测试 的主规则：异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射。选项“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”是使用规则时要验证的边界，不是规则本身；“未 await 的 Task 失败会稳定让当前测试立即失败”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0874 测试显示通过但后台 Task 稍后抛异常。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“未 await 的 Task 失败会稳定让当前测试立即失败”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”。
- C. 以一次成功请求作为结论，不再确认“异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射”是否成立。
- D. 先验证“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”，再依据“异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“测试显示通过但后台 Task 稍后抛异常”指向 取消与异常测试，但症状本身不能证明根因。正确排查应先确认边界“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”，再用主规则“异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射”解释证据。直接采用误区“未 await 的 Task 失败会稳定让当前测试立即失败”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0875 关于 取消与异常测试，以下哪项说法不成立？
难度： 实战
- A. 异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射
- B. 不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态
- C. 未 await 的 Task 失败会稳定让当前测试立即失败
- D. 出现“测试显示通过但后台 Task 稍后抛异常”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“未 await 的 Task 失败会稳定让当前测试立即失败”正是 取消与异常测试 的典型误区。其余三项分别给出了主规则“异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射”、适用边界“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0876 针对“测试显示通过但后台 Task 稍后抛异常”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射”修正实现，并用测试或遥测验证“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”。
- B. 按“未 await 的 Task 失败会稳定让当前测试立即失败”修改实现，并把一次请求成功作为验收结果。
- C. 按“异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射”修改代码后直接上线，不验证“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”。
- D. 只验证“不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态”，但实现仍继续依赖“未 await 的 Task 失败会稳定让当前测试立即失败”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：异步单元测试应 await 被测方法，并覆盖取消、超时和依赖异常映射；并确认 不要使用 async void 测试方法，也不能只断言异常类型而忽略副作用状态。继续接受“未 await 的 Task 失败会稳定让当前测试立即失败”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“测试显示通过但后台 Task 稍后抛异常”这一生产场景能否安全上线。
0877 在 时间与随机性 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式
- B. 安全随机数仍应使用密码学 API，测试替身不能进入生产配置
- C. 通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性
- D. 观察到“CI 负载变化导致时间测试随机失败”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 时间与随机性 的主规则：通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性。选项“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”是使用规则时要验证的边界，不是规则本身；“在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0878 CI 负载变化导致时间测试随机失败。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”。
- C. 以一次成功请求作为结论，不再确认“通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性”是否成立。
- D. 先验证“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”，再依据“通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“CI 负载变化导致时间测试随机失败”指向 时间与随机性，但症状本身不能证明根因。正确排查应先确认边界“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”，再用主规则“通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性”解释证据。直接采用误区“在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0879 关于 时间与随机性，以下哪项说法不成立？
难度： 实战
- A. 在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式
- B. 通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性
- C. 安全随机数仍应使用密码学 API，测试替身不能进入生产配置
- D. 出现“CI 负载变化导致时间测试随机失败”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式”正是 时间与随机性 的典型误区。其余三项分别给出了主规则“通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性”、适用边界“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0880 针对“CI 负载变化导致时间测试随机失败”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式”修改实现，并把一次请求成功作为验收结果。
- B. 按“通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性”修正实现，并用测试或遥测验证“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”。
- C. 按“通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性”修改代码后直接上线，不验证“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”。
- D. 只验证“安全随机数仍应使用密码学 API，测试替身不能进入生产配置”，但实现仍继续依赖“在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：通过 TimeProvider、随机数抽象或输入参数控制时间与非确定性；并确认 安全随机数仍应使用密码学 API，测试替身不能进入生产配置。继续接受“在测试中 Thread.Sleep 是验证所有超时和周期逻辑的最稳定方式”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“CI 负载变化导致时间测试随机失败”这一生产场景能否安全上线。