是否真的很棒的程序员使用单元测试？

Question

我想知道真正伟大的程序员（Knuth，Kernighan，Torvalds等）是否是广泛的单元测试的倡导者。我可以想象他们为解决协作扩展问题而加入它们的大型项目，但是，Knuth在TeX中使用单元测试吗？这并不会影响我决定使用它们，这只是好奇心问题。

Answer 1

在此interview Knuth解释说他不是狂热的单位测试者：

  

“单元测试”只对我有吸引力   很少，当我感觉到我的方式   完全未知的环境和需求   关于什么有效和什么的反馈   不

在同一回复中，他解释了他如何赢得斯坦福编程竞赛（比赛），同时成为在批量大型机上使用穿孔卡的唯一参赛者 - 所有其他人都在分时系统上使用这些新奇的互动终端当然，第二名终结者比Knuth花了一个多小时。

如果（在完全未知的环境中进行探索性编程除外）你对穿孔卡和批量大型机比对交互式终端和时间共享感觉更舒服，我认为确实会说单元测试不适合你的风格; - 。）

Answer 2

Joshua Bloch does：

  InfoQ：你相信其他工具吗？   和单元测试等过程，   测试驱动开发或配对   编程也有助于编程   在Java中有效吗？

     

Joshua Bloch：绝对。单元测试   是关键。并首先编写测试   是一件好事。

Answer 3

Knuth doesn't unit test.

  

至于你真正的问题，立即编译和“单元测试”的想法很少吸引我，当我在一个完全未知的环境中感觉我的方式，并需要有关哪些有效，哪些无效的反馈。否则，很多时间浪费在我根本不需要执行或甚至不需要考虑的活动上。没有什么需要“嘲笑”。

当然，Knuth还说*：

  

谨防上述代码中的错误;我只是证明它是正确的，没有尝试过。

Knuth是一个超级天才，但事实上他没有对他的代码进行单元测试，这不应该表明我们凡人不应该测试我们的代码。

Answer 4

Knuth是rather against unit testing and mocking。

Answer 5

是的，有很多优秀的程序员在进行单元测试。 Martin Fowler，Robert C“Uncle Bob”Martin，Michael Feathers，当然还有Kent Beck。问题不是“Jon Skeet练习单元测试吗”你可以使用Jon Skeet的代码并知道你是否破坏了它？您可以使用自己两年前编写的代码，并知道是否破坏了它？最后......你的办公室里有多少QA人？你花了多少时间用QA软件为你赚钱？你能多快识别出错误？

我们采取的单元测试是为了将开发软件的成本提高到一开始，当它更便宜时，20个QA人员开始关注它之前以及因为无法快速修复错误而导致客户流失。 / p>

我知道我永远不会雇用一个认为他们超过单元测试的开发人员，即使他们是世界上最吵闹的程序员。因为如果他明天被一辆公共汽车撞到我会找到一个人脑完全相同的人吗？

Answer 6

我个人不知道这些人是否提倡正式的单元测试

但请记住，Kent Beck解释说TDD应该被认为是伟大程序员自然使用的实践类型的形式化，甚至没有意识到。这对于我们糟糕的人来说，他们不是天才并帮助我们编写更强大的代码，使其更具适应性，并防止人们浪费时间编写一堆从未使用过的代码。我发现他完全符合评估标准。

Answer 7

可能不是。

然后，所有程序员通常称之为“真正伟大”的是25年前自己编写开创性软件的大型天才，通常是为了其他程序员，在单元测试流行之前，在版本控制普及之前，大规模协作项目之前是常态，等等。

换句话说，现代软件开发的特征是单元测试的参数，而这些参数当时并不是真正的。 现代真正伟大的程序员可能是单元测试，只是我们不称他们为好。

为了记录，我讨厌单元测试。称之为致敬。

Answer 8

从阅读Ayende's blog，我得知他的一些最成功的项目没有任何或许多单元测试。但是，他确实在许多项目中使用它们，而不是通常所有项目。 （再次从我从阅读他的博客中收集到的内容）。

Answer 9

Jon Skeet尝试了单元测试，但他的所有测试都没有通过代码。

或类似的东西。