测试驱动开发 测试前移_测试驱动开发的真相

测试驱动开发 测试前移

您对测试驱动开发的实用介绍

如今，您阅读了大量有关进行测试驱动开发（TDD）的所有优点的文章，并在技术会议上听到很多演讲，告诉您“进行测试！”以及执行这些测试有多酷。 你知道吗不幸的是，它们是正确的（不一定与“酷”部分有关，而与有用部分有关）。

测试是必须的 ！ 在谈到TDD时，我们列出的典型优势是真实的：

• 您编写更好的软件
• 引入新功能后，您可以免受破坏
• 您的软件是自记录的
• 避免过度设计

即使我一直都同意这些优点， 但有时我还是以为我不需要TDD来编写优秀且可维护的软件。 当然，现在我知道我做错了，但是尽管职业选手闪闪发光，我为什么仍然有这个主意原因仅仅是一个。

花费很多

成本

花费很多！ 可能有人在思考“ 但如果不进行测试，则成本甚至更高 ” —这也是正确的。 但是，这两个成本发生在不同的时间：

• 你做TDD?现在就要花钱了 。
• 您不做TDD? 将来会付出代价的 。

那么，我们如何摆脱这种僵局呢

完成某件事的最有效方法是尽可能自然地完成某件事。 人的本性是懒惰（这里的软件开发人员是表现最好的人）和贪婪的人，所以您现在必须找到降低成本的方法 。   这很容易说，但是很难做到！

在这里，我将分享我的经验以及为我带来利益/成本比率方面的成功经验。 但是在我这样做之前，让我们分析一下应用TDD的一些典型困难。

您可以测试两个数字的和吗/span>

一般来说，理论不是可选的。 您必须掌握它才能掌握练习。 但是，尝试一次应用您先前已获得的所有理论知识可能会产生以下效果：

您不能一次花费所有这些知识

关于TDD的典型理论课始于以下内容：

在这里你就像

很简单，不是吗

然后是这样的：

• 红色?绿色?重构周期
• 单元，验收，回归，集成测试
• 嘲笑，存根，假货
• 如果您很幸运（或者可能很不幸），有人会告诉您有关合同测试的信息，
• 如果您很幸运（或者可能很不幸），您将接触到遗留的代码库重构

事情变得艰难，但是您是一位经验丰富的开发人员，所有这些概念对您来说都不难处理。 然后，课程结束； 您回家，然后在接下来的几天里，您会认真地做一些代码修改以修正刚刚学到的概念。 到目前为止，一切都很好。

挣扎是真的

接下来是一个具有真实期限和真实计时成本的真实项目-但您有动力应用有光泽的新TDD。 您开始考虑软件的体系结构，并开始为第一类和该类本身编写测试-我们将其称为 。

在这一点上，你的内心，你开始听到一点声音，说：“ 我 会更快发展，如果我没有写这些测试…”。 您不会听这种邪恶的声音，而直接进行下一个测试。

将使用 ，并将其自身在Db中。 那么，我们是否必须测试 ，它与交互以及在Db中的持久性但是等等……有人在TDD理论课上有没有提到如何应对I / O测试

好我辞职了

TDD背后的理论并不难理解，但如果您未采用正确的方法，将其应用于现实世界可能会非常复杂。

去做就对了

我们应该始终牢记，理论必须紧贴我们的需求，而不是相反。

主要目标是完成工作。 所以我的建议是， 随便做吧 ！

从简单开始，直到完成任务。 然后，当您陷入某些理论思维循环时，例如：

暂时忘记理论，然后向前迈进。 随它来吧！ 完成任务后，请回顾一下您的工作。 回顾完成的工作，将更容易分析什么是正确的事情。

实用TDD

去做就对了。 顺便说一句，我认为这也是解决TDD的正确方法。

我们如何构建 ， 和什么问题该方法。

这是一种自下而上的方法：

• 分析问题
• 弄清楚一种架构
• 从单元组件开始构建

这种方法是过度工程的最好朋友。 通常，您构建系统是为了防止您认为将来会发生更改，而又不知道它们是否确实会更改。 然后，当某些需求发生变化时，无论它有多好，通常都会以不适合您的结构的方式发生。

对我而言，大幅降低使用TDD进行写作的即时成本的关键在于采取自上而下的方法：

• 带来用户故事
• 写一个非常简单的用例测试
• 使其回到步骤2，直到完成所有用例

在执行此过程时，不必过分担心体系结构，干净的代码（嗯，至少要记住使用体面的变量名）或当前不需要的任何复杂形式。 尽一切所能 ，直到最后。

对故事的测试清楚地说明了当前和已知的要求。

完成后，请看一下意大利面泥浆代码的大丸子，摆脱耻辱，然后更深入地了解已完成的工作：

看你做了什么

有用！ 测试证明了这一点。所有系统都在那里， 而完成工作实际上需要什么 。

现在，您已经了解了系统的所有部分，因此您可以借助从头开始时没有的域知识来进行重构。 并且测试将确保重构时不会破坏任何内容。

重构

对我而言，开始重构的最佳方法是确定责任范围并将其划分为私??有方法。 此步骤有助于确定职责及其输入和输出。

在继续操作时，为从过程中弹出并迭代的类编写测试，直到对结果满意为止。 记住，如果您被卡在某个地方，那就去做吧！ 如果您做的不好，一旦完成，您将获得更多有关如何在下次遇到错误时克服错误的信息。 尽您最大的能力，把工作做好是最重要的。

这样，如果您分析错误以从中学习，您还将提高自己的能力。

下一个用户故事

请按照以下步骤继续开发产品：

• 讲一个故事
• 使它完全在“测试-代码”循环中工作
• 重构

添加功能时，您将继续更改软件，甚至可能更改其结构。 但是随着系统的发展，由于TDD的两个主要功能，变更成本将保持线性增长：

• 架构发现（有助于控制复杂性）
• 保护免受重大更改

该系统不会进行过度工程设计，因为随着故事的完成，架构将会出现。 您无需考虑将来的需求； 如果最终需要它，则实施它的成本将很低。

有什么可能使它出错/span>

故事的大小。 最终构建的内容必须是正确的大小。 不太大（否则将花费太多时间来获得任何反馈）或太小（否则您将没有概述）。

如果故事太大了怎么办将其拆分为可以从头到尾构建的部分。

感谢您的阅读！

图片归功于 https://testsigma.com/blog/ai-driven-test-automation/

翻译自: https://hackernoon.com/a-practical-intro-to-test-driven-development-hb63i319u

测试驱动开发 测试前移

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92175 人正在系统学习中 相关资源：渣浆泵的计算机选型软件及应用.rar-制造文档类资源-CSDN文库