2.1 单元测试与自动测评机相比有何优劣，能否在一定条件下被替代，或者说互补？

[GreyZeng]

问题来自于：https://www.cnblogs.com/Ethanscript/p/14952706.html

[GreyZeng]

可以说还没进行软工实践时，我对单元测试并不感冒，认为其与编写自动评测机进行测试没有可比性。然而通过Beta阶段团队项目的测试工作，我体会到，单元测试与其说是简单的进行程序正确与否的判断，不如看作给予程序开发者“再一次思考模块可行性”的机会。例如我在Beta阶段对ChampionShop.cs模块进行检查时发现GetRandomChampionInfo()的随机过程似乎实现有误，通过对该函数进行单元测试发现，由于在Alpha阶段我们默认了分配卡牌的数量，而由于Beta阶段我们新增了大量卡牌，原本的实现方式会导致refresh时选取卡牌操作会每次从默认牌组头部进行遍历，若卡牌已经由后端提供则跳过，对剩下部分进行随机，最终导致默认牌组靠前的卡牌更容易选出的伪随机效果，不符合设计初衷。

可以想见，即使不考虑真实工程中实现的可能性，这类细节性的错误很难通过较为宏观的自动评测机进行检验，而“强制”的单元测试则“迫使”代码的书写者在完成相应模块后重新对整个模块进行可行性的分析，根据贝叶斯定理，这里更要求书写者站在外部视角（用户的角度）来对该模块进行测试，以保障不陷入内部视角的思维局限。同时针对各个模块单独进行单元测试，也能使各模块相互独立，“保证即使模块内部的改变也不会影响其他模块，而且模块的质量能够得到稳定的、量化的保证”，这也是实际软工中行而有效的良方。

原文地址