单元测试的新名称[关闭]

我从不喜欢单元测试。我一直认为这增加了我要做的工作量。
事实证明，仅就您编写的实际代码行数而言，这是正确的，此外，您可以在一小时内通过测试和测试驱动的开发编写的有用代码的行数增加完全抵消了这一点。

现在，我喜欢单元测试，因为它们允许我编写有用的代码，而这些代码通常在第一次使用时就可以使用！（敲木头）

我发现，如果人们在严格的时间表内或在其他人不这样做的环境中，他们不愿意进行单元测试或以测试驱动的开发开始项目。有点喜欢，一种文化拒绝甚至尝试。

我认为关于单元测试的最强大的功能之一就是它给您进行重构的信心。这也给我带来了新的希望，我可以将我的代码提供给其他人进行重构/改进，并且如果我的单元测试仍然有效，那么我可以使用他们修改过的新版本的库，几乎不用担心。

我认为这是单元测试的最后一个方面，需要一个新名称。单元测试更像是该代码现在和将来应该做什么的合同。
当我听到“测试”一词时，我想到了关在笼子里的老鼠，并对其进行了多次实验，以观察化合物的有效性。这不是单元测试，我们不是在尝试不同的代码来了解什么是最有影响力的方法，而是在定义我们期望的输出和输入。在老鼠的例子中，单元测试更像是宇宙如何工作的定义，而不是在老鼠身上进行的实验。

我是处于崩溃状态还是其他人看到拒绝进行测试，他们是否认为这是他们不想这样做的类似原因？
您/其他人给出不测试的原因是什么？
您认为他们的动机不是单元测试吗？

作为单元测试的新名称，它可以克服某些异议，jContract呢？（我知道一点Java中心：）还是单位合同？

我是处于崩溃状态还是其他人看到拒绝进行测试，他们是否认为这是他们不想这样做的类似原因？

单元测试中的测试一词使人们认为这是集成测试或用户界面测试，因为那是他们做过的唯一测试。就像将Java放入javascript中一样。

当某件商品的名称不好并影响人们对其的思考时，这称为成帧错误。取景错误往往是肤浅的-人们很聪明，可以看穿各种不良名称，不良隐喻。

您/其他人给出不测试的原因是什么？

难以模拟/伪造/

您认为他们的动机不是单元测试吗？

单元测试的概念数量很少，在停止编写不良的单元测试并开始编写好的单元测试之前，需要完成大量的工作。随着人们更好地解释什么是单元测试，采用率将会增加。以我的经验，单元测试对生产力和代码质量几乎具有神奇的影响。但这并不是从那开始的。我最初使用单元测试框架作为编写集成测试的便捷方法。

已经提出了更改名称的概念。这就是所谓的行为驱动开发。提出这一点的家伙注意到了很多相同的论点，加上不自然地适合测试尚未创建的东西。相反，他们的概念是编写一个可执行规范（无论如何，TDD实际上就是该规范）。

我注意到了同样的回推。我还注意到，许多人只是不知道如何编写单元测试。他们缺乏科学的过程学科，仅使用单元测试框架作为将所有内容连接在一起并启动调试器的方式。简而言之，他们并没有真正改善时间的利用。我无法告诉您，我已经看到多少个单元测试是几十行长（30多个行），而不是一个assert语句。当我看到这一点时，我知道是时候与开发人员合作，并教他们什么是断言，以及如何编写实际测试的单元测试。

在大多数情况下，合同被称为“接口”。进行单元测试并不能保证合同本身，因为您也可以更改测试，因此您实际上并不知道可以仅仅因为测试了库就使用新版本的库。您还需要测试使用该库的代码。这与其他任何单元测试都没有什么不同，所以我不明白为什么这需要一个新名称。

我认为，像您一样，大多数人都不愿意进行测试，因为他们认为这是更多的工作，没有用。

我将告诉您为什么不喜欢TDD：不是因为我看不到TDD的价值，还是因为我认识到测试套件的好处，我可以在每次修改后运行该套件来验证所有代码。

这是因为我不需要它。我是一个非常老派的开发人员，当我还是个小伙子的时候，我们没有像花哨的集成调试器那样可以编辑并继续编写代码，而且编译可能要花很长时间，所以我们不得不做些事情对，从一开始就对。经过这样的培训，我真的看不到编写大量的单元测试会提高我的生产力，也不会使我的代码更没有错误。

我确实测试了我的代码，但是正如我一直所做的那样，这是整个问题的一部分，而不是各个部分。因此，也许我确实有“单元测试”，但它们的粒度更粗。

这就是我的原因。我看不到我需要这样做。我生成的代码足够好，如果是这种情况，为什么我应该更改流程以修复未损坏的内容？