什么是tdd开发
尽管在编程行业中首字母缩写词的总数可能已经超过了在无月夜空上可以观察到的星星的数量，但只有一部分得到了普及和认可。 TDD肯定属于这个组。 从众多会议演讲，书籍，播客和博客文章来看，测试驱动开发是一种广为人知的技术，这一事实是不可否认的。 但是，当您考虑采用和实际使用时，实际情况可能会有所不同。 在本文中，我们将探讨候选人在进行的几次技术面试中提出的避免使用TDD的不同原因，并试图证明它们是否是真正的障碍。
1.“管理不允许我们”
这里可能要问的问题是，为什么管理层决定开发人员是否应该使用TDD。 医生会问医院主任是否允许他使用医用手套？ 当然不是，因为他使用它们来保护自己。 他也没有咨询他开给病人的每种药物。 作为专家，他被允许在问责制方面做出自己的决定。
同样，开发人员可以查看他们的工具集和技术。 您的目标是有效交付软件，并且作为专业人员，您有责任找到实现方法。 没有什么可以阻止您尝试小功能来评估该技术对您是否有用，或者更像是球和链。
非技术经理实际上无法掌握TDD的全部含义。 他们中的许多人将“测试”与“质量分析”联系在一起，并且由于许多组织中都有专门的质量检查人员来从事这项工作，因此他们不理解为什么开发人员应该重复他们的工作。 试图解释差异是没有意义的。 添加新功能后，您可能不会向经理解释选择了哪些数据结构来完成任务，因为这不是他们感兴趣的详细信息级别。TDD属于同一级别。
2.“没有足够的时间编写测试”
第二个借口（不仅适用于TDD，而且适用于所有类型的自动化测试）与第一个借口非常相似，但由于其原因可能不尽相同，因此应单独查看。 尽管经理们经常试图设定紧迫的期限，但开发人员有责任评估自己过分乐观的态度，并在适当时表示不同意。 您最好评估完成一项任务所需的工作量。 确保您的估计包括编写自动化测试。
这里的问题是，开发人员喜欢以其效率给其他人留下深刻的印象，并且有时接受的任务数量超出了预计的实际完成时间。 如果最终一项任务花了比最初预期更多的时间，而是承认自己低估了他们，他们通常会辞职以编写测试，以满足“承诺的”交付时间。 如果您不推迟针对某个功能编写一组测试，而是按照TDD的建议将它们与生产代码一起编写，则您将永远没有机会退出测试。
3.“我的团队不同意我们是否应该使用TDD”
在进行软件项目时，会有影响每个团队成员的决定（例如选择框架或打包组织），并且每个人都应该同意或由团队负责人强加。 但是，TDD是其中一项决定吗？ TDD是否可能只有少数团队成员工作？
在鲍伯叔叔的文章中，我们可以读到这是不可能的。 如果这样的团队评估TDD的一部分而其他依赖集成测试，则最终结果将始终是相同的-分离。 最终，如果其他公司需要的话，开发人员将寻求能够分享其价值的团队。
幸运的是，还有一个积极的分歧，鲍勃叔叔没有提到。 有些团队将那些看重自动化测试的人与那些不编写任何类型的测试的人分开。 在这种情况下，某些团队成员可以成功引入TDD，而不会引发冲突。 通过举例说明，随着时间的推移，更多的队友可能会对TDD产生兴趣。
4.“未证明对TDD的投资回报率”
许多人要求提供有关TDD有效性的科学证明，他们绝对有权利这样做。 毕竟，他们将在技术上花费自己的时间，因此对投资的评估似乎是合理的。 但是，关于缺乏证据的说法是不正确的，因为可以向TDD怀疑论者提供一些值得信赖的消息来源。
第一篇是Boby George和Laurie Williams在2003年撰写的北卡罗来纳州立大学的论文 。 TDD的反对者通常将这种技术妖魔化为极其耗时，但是该文件表明，研究的TDD从业人员小组在整个开发过程中仅花费了16％的时间。
Nachiappan Nagappan等人在2008年记录了另一个实验。 在三个Microsoft和一个IBM开发团队上进行的，与相似的项目相比，预发布错误的总数显着减少了（介于40％和90％之间）。
您可以在网络上找到更多的研究，但是我们不能忘记不可能一概而论，因为每个软件项目都是不同的，有些领域很难比较，因此确切的数字在各种情况下都不相同。 这些论文的真正收获是，TDD可以提高软件质量，这是可观察到的事实，但是您应该确定所需的时间投入是否值得在特定情况下付出的代价。 当品牌因软件错误而遭受损失时，最好尽早发现它们。 但是对于后台工具，更容易解决用户发现的问题。 测试驱动开发不是灵丹妙药。
5.“我们尝试过，但是没有用”
不良的学习经验会有效地阻止软件开发人员使用任何技术。 当将TDD应用于设计时未考虑可测试性和模块化的遗留代码时，可以观察到这种效果。 在旧系统中通常会出现的上帝对象是单元测试的发誓敌人。 传统代码并不是评估TDD的最佳场所。
当将TDD应用于不需要单元测试的代码时，也会发生此问题。 纯粹主义者可以说您应该争取100％的代码覆盖率，但是在现实生活中，这样的目标是浪费时间。 每个应用程序都由某种业务逻辑和毫无头脑的胶水代码组成。 尽管TDD对于第一个组来说很棒，但对于第二个组来说，就像用大锤敲打坚果一样。 这样的代码通常协调操作序列，并且可能具有许多依赖关系，这些依赖关系需要大量的模拟才能进行测试。 大量的模拟和间接结果断言也可能导致对TDD的不良印象，在这种情况下，这仅仅是对技术的滥用。
6.“构建过程缓慢”
进行缓慢测试的一种可能原因是其设置的复杂性。 如果选择用于测试的单元太大，则准备启动状态可能会花费大量时间。 慢速运行的测试可以看作是一个红旗，表示您应该更仔细地研究应用程序的设计并评估被测元素之间的耦合。 运行时间最长的测试可以轻松找到并单独解决。
还值得一提的是，没有理由在Red Green Refactor流程中运行所有应用程序测试 。 在设计合理的项目结构中 ，仅选择这些专门针对代码库中当前更改部分的测试应该没有问题。
运行缓慢的测试的另一个原因是它们的总数。 如前所述，每个应用程序的某些部分根本不需要测试。 代码覆盖率指标的提高只是在骗子自己提高了软件质量。 自动化测试应该关注于变化很大的代码，业务逻辑，计算等。学会评估在什么情况下不需要它们。
7.“我不知道写所有测试的所有先决条件”
这是一个误解该技术概念的示例。 TDD并不是要在编写生产代码之前为给定的代码单元创建所有可能的测试方案，而是要发现测试用例以及已实现的需求 。 TDD的全部优点在于，可以放心地逐步添加新的逻辑，因为先前涵盖的需求的回归是通过测试进行的。 TDD是一个迭代过程，其中生产代码和测试是交替创建的。
自然，通过连续编写一些测试来加快周期没有错。 肯特·贝克（Kent Beck）在他的《测试驱动的开发：示例》中承认，只要您了解要解决的问题，就不必严格遵守“红色绿色重构”周期。 请记住，如果您感到有需要，在处理更复杂的挑战时总是可以放慢脚步。
TDD专家的一些技巧
通过从他人的错误中吸取教训，可以最大程度地减少TDD的不良印象。 如果您是以下TDD之旅的开始，则可以找到一些一般性提示，这些提示可以简化学习过程。
- 让我们从一个真实性开始：所有的开端都是艰难的。 预计最初用于开发新功能的时间会增加。 学习新事物，无论是框架，乐器还是陌生的技术，都需要花费时间。 为了改善，您需要克服重返旧生活的诱惑。
- 专注于在实现生产需求之前编写测试。 这将迫使您考虑代码模块化，并影响您设计类及其关系的方式。
- 旧版代码并不是TDD最令人愉快的地方。 新功能应该不会造成任何问题，但是在现有的整体代码库中添加测试可以Swift降低您对该技术的期望，因为它肯定更具挑战性。
- 100％代码覆盖率的目标是一个神话，也是TDD不信任者将其描述为浪费时间的原因。 专注于业务逻辑所在的软件的最关键部分。
- Web上有很多可用的资料，但是如果您需要推荐，则应查看TDD倡导者肯特·贝克（Kent Beck）编写的“测试驱动开发：示例”。
- 提高您的单元测试技能。 框架随处可见，但是将时间花在学习如何编写正确的自动化测试上将非常有用。
- 带有偏见的旁注：在测试未涵盖的代码中进行更改会带来很大压力。 TDD对您的健康有好处＆＃55357;＆＃56898;
您会添加什么？
测试优先的方法已经存在了将近20年，但是对其生产率的怀疑仍然很普遍。 希望提出的例子可以说服那些对采用TDD有所犹豫的人。 如果您发现了该帖子未涵盖的任何其他借口，或者为初学者提供了提示，则评论部分正在等待您的光临。 也许您经历过该技术的有害影响，并且值得分享这个故事？ 您的知识可以帮助避免其他开发人员遇到的问题。 感到被邀请参加讨论。
翻译自: https://www.javacodegeeks.com/2018/02/developers-dont-use-tdd.html
什么是tdd开发
1万+
