在我的商店里，对一般的单元测试并不熟悉，但我想进入它，至少作为概念的证明。在我的小型（~500行）代码库中简单地使用Visual Studio函数创建单元测试并以这种方式显示概念是不是一个疯狂的想法？
答案 0 :(得分：3)
根本不是一个疯狂的想法，只要知道你应该从这种方法中获得什么。
如果你只想展示如何对现有代码进行单元测试，这就是Roy Osherove所说的TAD（开发后测试），它是一种快速简便的方法来展示应该测试哪种东西。
如果你是单元测试，因为你有兴趣转向TDD，那么你的方法可能会混淆，而不是启发。在我看来，试图通过向现有代码添加单元测试来向某人展示TDD会失败。
相反，我会研究一些东西（比如SpecFlow），它试图关注TDD的精神，即你在编写真正的代码之前在测试代码中编写规范（或要求）。它有效。
当我意识到在代码之前编写的单元测试实际上是我非常详细的要求时，一个灯开关向我翻转。它是自我记录的，只要单元测试（规范）写得正确，那么我的工作代码就能保证满足要求！
如果您同意这一点，您可能需要查看Bowling Game Kata。我发现它对引入单元测试和TDD概念很有帮助。
答案 1 :(得分：0)
不，这根本不是疯了，恕我直言是一个好主意。
团队或公司进入单元测试文化的唯一方法就是有人开始使用它。如果不这样做，现有的人不太可能不熟悉这个概念。
一个可能更好的想法是抓住你板上的几个错误并编写重现失败的单元测试。演示测试捕获真正的错误并验证解决方案。我发现对于那些不熟悉单元测试概念的人来说，这通常是相当引人注目的。