测试驱动开发 测试前移

by Navdeep Singh

通过Navdeep Singh

测试驱动的开发可能看起来是工作的两倍-但无论如何您都应该这样做 (Test-driven development might seem like twice the work — but you should do it anyway)

Isn’t Test Driven Development (TDD) twice the work? Should you do it anyway?

测试驱动开发(TDD)是否是工作的两倍？ 反正你应该这样做吗？

The short answer to the first question is NO. On the surface, it may seem like without TDD, time is only required to create the feature. With TDD, you need time to create the test AND create the feature, thus doubling the development time required.

对第一个问题的简短回答是“ 否” 。 从表面上看，似乎没有TDD时，创建功能仅需要时间。 使用TDD，您需要时间来创建测试和创建功能，从而使所需的开发时间加倍。

What you’re not considering is the amount of time required for QA testing and debugging when the feature isn’t performing properly.

您不需要考虑的是功能无法正常运行时进行质量检查测试和调试所需的时间。

Case studies were conducted with three development teams at Microsoft and one at IBM that adopted TDD. The results of the case studies indicated that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice.

案例研究由Microsoft的三个开发团队和采用TDD的IBM的一个开发团队进行。 案例研究的结果表明，相对于未使用TDD做法的类似项目，四种产品的预发布缺陷密度降低了40％至90％。

Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD. (source)

从主观上讲，采用TDD后，团队的初始开发时间增加了15–35％。 ( 来源 )

That 40–90% decrease in pre-release defects means that QA teams and customers weren’t finding and reporting those issues. Engineering wasn’t trying to recreate bugs and develop patches, all of which have associated costs.

预发布缺陷减少40–90％，意味着质量检查团队和客户没有发现并报告这些问题。 工程部门并没有尝试重新创建错误并开发补丁，所有这些都会带来相关的成本。

When discussing TDD, we consider a task to be a subset of a requirement that can be implemented in a few days or less. TDD software engineers develop production code through rapid iterations, as shown in the figure above.

在讨论TDD时，我们认为任务是可以在几天或更短时间内实现的需求的子集。 TDD软件工程师通过快速迭代来开发生产代码，如上图所示。

什么是TDD？ (What Is TDD?)

Test-Driven Development is an approach to writing software in which the developer uses specifications to shape the way they implement a feature. For short, we describe it as the “red-green-refactor cycle”.

测试驱动开发是一种编写软件的方法，开发人员使用该规范来规范其实现功能的方式。 简而言之，我们将其描述为“红绿重构周期”。

Before writing any code that adds new functionality to an application, the developer first writes an automated test describing how the new code should behave, and watches it turn red (fail to pass). They then write the code to the specification, and the test turns green (it passes). Finally, the developer takes a little time to make sure that the code just written is as clean as possible (refactoring).

在编写任何向应用程序添加新功能的代码之前，开发人员首先编写一个自动测试，描述新代码的行为，然后观察它变成红色(失败)。 然后，他们将代码写入规范，然后测试变为绿色(通过)。 最后，开发人员需要花费一些时间来确保刚编写的代码尽可能干净(重构)。

为什么您应该关心TDD (Why you should care about TDD)

Automated testing gives your software developers the confidence to make changes to the software and to know that no bugs were created as a byproduct.

自动化测试使您的软件开发人员有信心对软件进行更改，并知道不会产生任何作为副产品的错误。

Additionally, it allows more agility for developers who aren’t familiar with the details of the software to confidently modify the source code without introducing errors.

此外，它为不熟悉软件细节的开发人员提供了更大的灵活性，使他们放心地修改源代码而不会引入错误。

Let’s discuss some really cool advantages of TDD.

让我们讨论一下TDD的一些非常酷的优点。

1. TDD帮助您防止错误 (1. TDD Helps You Prevent Bugs)

First, test suites ensure comprehensive test coverage of the codebase, so bugs are less likely to pop up unnoticed. Second, test suites allow developers to work out potential issues before the application is ready to go into production. Finally, because test suites are constantly maintained, they guarantee software quality.

首先，测试套件可确保对代码库进行全面的测试覆盖，因此，漏洞很少被忽视而不会弹出。 其次，测试套件允许开发人员在应用程序准备投入生产之前解决潜在问题。 最后，由于测试套件不断维护，因此可以保证软件质量。

2.自我解释代码(有据可查) (2. Self Explanatory code (well-documented))

Because refactoring code is a built-in step in TDD, you end up with a much cleaner codebase as you go. Apps built with TDD tend to have less duplication, fewer edge cases that aren’t thought through, and a better overall architecture.

由于重构代码是TDD中的内置步骤，因此最终会获得更加简洁的代码库。 使用TDD构建的应用程序往往具有更少的重复，更少的未被考虑的边缘情况以及更好的整体架构。

The test serves as a specification for what the code that will be written should do. As long as you’re writing good stories, your development team should be able to build exactly what you asked for. If your team agrees to use Acceptance Test-Driven Development, you can even write tests that describe how you want it to work in plain English!

该测试用作将要编写的代码应该做什么的规范。 只要您编写好的故事，您的开发团队就应该能够完全按照您的要求进行构建。 如果您的团队同意使用验收测试驱动开发 ，您甚至可以编写测试来描述您希望它以普通英语工作的方式！

3.避免错误调试器问题 (3. Avoid the bugger debugger problem)

Typically, when talking tech about software development, there are two main types of testing that can be integrated: functional and non-functional. These two types of testing practices are further divided into numerous types of testing techniques as you can see here:

通常，在谈论有关软件开发的技术时，可以集成两种主要的测试类型：功能测试和非功能测试。 您可以在此处看到这两种类型的测试实践进一步分为多种类型的测试技术：

It becomes really important to strategize the testing plan before project commencement, since that helps in clearly defining the roles and responsibilities of developers with respect to testers when it comes to testing.

在项目开始之前制定测试计划的策略非常重要，因为这有助于明确定义开发人员在测试方面相对于测试人员的角色和职责。

For example:

例如：

• Unit and Integration tests to be performed by developers before handing out builds to testers
  由开发人员执行的单元和集成测试，然后再将构建交付给测试人员
• User acceptance testing to be performed by the testers
  测试人员要执行的用户接受度测试
• Performance testing and UI testing should be done by both
  性能测试和UI测试应同时进行

A brief description of a few very important testing methodologies from the diagram above, that should be included in almost every test plan, are covered below.

下面涵盖了上图中一些非常重要的测试方法的简要说明，这些方法应该包含在几乎每个测试计划中。

Unit Testing involves testing individual units of source code to determine if they are fit for use. Intuitively, one can view a unit as the smallest testable part of an application. Faking, Mocking, and Stubbing are indispensable while writing unit tests for code which has API interactions.

单元测试涉及测试源代码的各个单元，以确定它们是否适合使用。 直观地，人们可以将一个单元视为应用程序中最小的可测试部分。 在编写具有API交互作用的代码的单元测试时， 伪造，模拟和存根 是必不可少的。

Integration testing involves a combination of two or more “units” being tested. Integration tests verify that the components of the software all work together or “integrate” appropriately.

集成测试涉及两个或多个要测试的“单元”的组合。 集成测试可以验证软件的各个组件是否可以协同工作或适当地“集成”。

Performance testing is used to ensure that software applications will perform well under their expected workload. The features and functionality supported by a software system are not the only concerns. A software application’s performance, like its response time, reliability, resource usage, and scalability, matters. The goal of performance testing is not to find bugs, but to eliminate performance bottlenecks.

性能测试用于确保软件应用程序在预期的工作负载下能正常运行。 软件系统支持的功能不是唯一的关注点。 软件应用程序的性能(如响应时间，可靠性，资源使用率和可伸缩性 )至关重要。 性能测试的目的不是发现错误，而是消除性能瓶颈。

4.您可以预测麻烦 (4. You can forecast troubles)

The benefit of a comprehensive test suite is that it alerts you to changes early. For example, if your checkout flow stops charging users’ credit cards, you’ll know it right away, because the tests will fail. It also means that if someone makes a mistake and something doesn’t work the way it was supposed to, it will be obvious.

全面的测试套件的好处在于，它可以提醒您及早进行更改。 例如，如果您的结帐流程停止向用户的信用卡收费，您将立即知道，因为测试将失败。 这也意味着，如果有人犯了一个错误，但某些事情却没有按预期的方式工作，这将是显而易见的。

This is good, because it will give you a chance to fix it before it goes to production. If it becomes necessary down the road, you can even start a campaign of deep refactoring without fear, because you’ll have an ironclad test suite that will remain green.

这很好，因为它将为您提供在生产之前对其进行修复的机会。 如果将来有必要，您甚至可以毫无顾虑地发起深度重构运动，因为您将拥有一个铁定的测试套件，它将保持绿色。

5.省钱 (5. Save Money)

When code is complicated, it gets much harder to get anything done — one little change over here can result in a big problem over there. When following TDD, developers can make changes with confidence and your QA team will catch fewer regressions. In development speak, “time saved is equal to money earned.”

当代码很复杂时，完成任何事情都变得更加困难-在这里进行一点更改可能会在那儿导致一个大问题。 在遵循TDD时，开发人员可以放心地进行更改，并且您的质量检查团队可以减少回归。 用发展的话来说， “节省时间等于赚钱。”

6.投资节省的时间进行创新和研究 (6. Invest the saved time in innovations and research)

If we just adopted a TDD approach, much of this money (time saved as expressed in point 5) could be spent on new innovations instead.

如果我们只是采用TDD方法，则其中的大部分钱(如第5点所述，可以节省时间)可以用于新的创新。

7. TDD帮助您避免示波器蠕变 (7. TDD Helps You Avoid Scope Creep)

The nightmare of any project manager is scope creep — any unexpected growth in the scope of work which leads to delays in project delivery.

任何项目经理的噩梦都是范围的蔓延-工作范围的任何意外增长都会导致项目交付的延迟。

Scope creep can happen for various reasons: poorly defined tasks, misinterpretation of project requirements, lack of documentation, and so on. There are many methods aimed at mitigating scope creep, and TDD is one of them.

可能会因各种原因而发生范围爬行：任务定义不正确，对项目要求的误解，缺少文档等。 有许多旨在减轻示波器蠕变的方法，而TDD就是其中一种。

Thanks for reading! Please share it if you found it useful :)

谢谢阅读！ 如果您觉得有用，请分享：)

翻译自: https://www.freecodecamp.org/news/isnt-tdd-test-driven-development-twice-the-work-why-should-you-care-4ddcabeb3df9/

测试驱动开发 测试前移