测试驱动开发 测试前移_对测试驱动开发的测试文化的观察

测试驱动开发 测试前移

by Doug Arcuri

由道格·阿库里(Doug Arcuri)

对测试驱动开发的测试文化的观察 (Observations on the testing culture of Test Driven Development)

This is not a primer on Test Driven Development. It contains my personal observations of re-starting the discipline and the problem of unit testing craft.

这不是“测试驱动开发”的入门。 它包含了我对重新开始该学科以及单元测试技术问题的个人观察。

Kent Beck, a software engineering leader, is also the modern day re-inventor of test driven development (TDD). Kent also cowrote JUnit, a widely used testing framework, with Erich Gamma.

软件工程主管Kent Beck还是现代的测试驱动开发(TDD)的重新发明者。 肯特还与Erich Gamma共同探讨了广泛使用的测试框架JUnit。

In his book, XP Explained (second edition), Kent describes that at the intersection of values and practices form principles. When we iterate from the concept and plug in what we believe as a formula, we achieve a transformation.

肯特(Kent)在他的《 XP Explained (第二版)》一书中描述了价值观和实践形成原则的交集。 当我们从概念中迭代并插入我们认为是公式的内容时，我们就实现了转变。

[KISS, Quality, YAGNI, ...] + [Testing, Specs, ...] == [TDD, ...]

I have a profound respect for Kent’s life work not only because of his brilliant software creations but also his continued exploration of trust, courage, feedback, simplicity and vulnerability. All attributes are paramount to the invention of Extreme Programming (XP).

我对Kent的一生都非常敬重，不仅因为他出色的软件创作，还因为他对信任 ， 勇气 ， 反馈 和 简单性的不断探索 和脆弱性 。 所有属性对于极限编程(XP)的发明都是至关重要的。

TDD is a principle and a discipline that is followed by the XP community. The discipline has been present for nineteen years.

TDD是XP社区遵循的一项原则和一门学科 。 该学科已经存在了十九年。

In this post, I will describe my opinion of where TDD stands in its adoption. Following this, we will explore intriguing personal observations as we perform TDD. Finally, we will conclude by postulating why TDD hasn’t taken off as it should. Let’s begin.

在这篇文章中，我将描述我对TDD在采用中的立场的看法。 此后，我们将在执行TDD时探索有趣的个人观察。 最后，我们将通过推测为什么TDD未能如期起飞而得出结论。 让我们开始。

TDD，研究和专业精神 (TDD, Studies, And Professionalism)

Nineteen years in, TDD is still debated as a discipline in the development community.

十九年来，TDD在开发社区中仍被作为一门学科进行辩论。

The first question an analytical person would ask, is “How many or what percentage of software professionals use TDD today?” If you asked a friend of Robert Martin (Uncle Bob), a friend of Kent Beck, the answer would be one hundred percent. This is because Uncle Bob believes that it is infeasible to consider being a professional if test driven development is not practiced. [1]

分析人员会问的第一个问题是：“今天有多少软件专业人员使用TDD？ 如果您问肯特·贝克的朋友罗伯特·马丁(鲍勃叔叔)的朋友，答案将是百分之一百。 这是因为鲍勃叔叔认为，如果不进行测试驱动的开发，那么考虑成为专业人士是不可行的。 [1]

Uncle Bob has been the focus of the discipline for some years now and it is natural to discuss him as a part of this write up. Uncle Bob has defended TDD and has pushed the discipline’s boundaries significantly. It should go without question that I too respect Uncle Bob and his pragmatic dogmatism.

鲍伯叔叔多年来一直是该学科的重点，很自然地将他讨论为本书的一部分。 Bob叔叔为TDD辩护，并大大突破了该学科的界限。 毫无疑问，我也尊重鲍伯叔叔及其务实的教条主义。

However, no one asks the follow up question “the definition of practice is the deliberate use of — but it does not specify amount or percentage of, right?” My subjective estimation is that a majority have not practiced TDD even in some small timeframe.

但是，没有人问到后续问题“ 实践的定义是故意使用-但未指定数量或百分比，对吗？” 我的主观估计是，即使在很小的时间范围内，大多数人也没有实践TDD。

The reality of the situation is that we actually do not know, since the practice percentage has not been studied widely. The only concrete measurement we have is a small collection of companies being gathered at WeDoTDD. Here, there is tracking of such companies. Interviews are conducted with those who practice 100% of the time, but that list is small. It is also incomplete since simple searching reveals other larger shops practicing — but perhaps not at full capacity.

这种情况的现实情况是我们实际上不知道，因为实践百分比尚未得到广泛研究。 我们唯一的具体衡量标准是WeDoTDD收集的一小部分公司。 在这里，跟踪了这些公司。 采访是与那些有100％的时间进行练习的人进行的，但是这个列表很小。 它也很不完整，因为简单的搜索显示其他较大的商店正在练习-但可能没有满负荷运转。

If we don’t know how many are practicing, the next question is “how effective is TDD based on measured benefits?”

如果我们不知道有多少人在实践，那么下一个问题是“基于测得的收益，TDD有多有效？”

You would be pleased to know that there have been studies conducted over the years that have proven TDD’s effectiveness. This includes the well recognized reports from Microsoft, IBM, North Carolina University, and the University of Helsinki.

您会很高兴知道，多年来进行的研究证明了TDD的有效性。 这包括来自Microsoft ， IBM ，北卡罗来纳大学和赫尔辛基大学的公认报告。

These reports prove to a degree that defect density is reduced by 40% to 60% in exchange for increased effort and execution time by 15% to 35%. These numbers have also begun to echo through books and new industry processes such as the DevOps community.

这些报告证明，缺陷密度降低了40％至60％，以换取增加的工作量和15％至35％的执行时间。 这些数字也开始在书籍和新的行业流程(例如DevOps社区)中回响。

With these questions half answered, the final question is “what should I expect as I start to perform TDD?” You are in luck, because I have formulated my own observations of TDD. Let’s review them next.

这些问题回答了一半后，最后一个问题是“开始执行TDD时我应该期待什么？” 您很幸运，因为我已经提出了自己对TDD的观察。 接下来让我们复习一下。

1. TDD命令表达一种方法 (1. TDD Commands Verbalizing An Approach)

As we practice TDD, we begin to experience a phenomena of “calling the shot”. In simple terms, the short acts of creating failing and passing tests will intellectually challenge the developer. They will say aloud “I think this will pass” and “I do not think this will pass” or “I’m not sure, let me think after I try this approach.”

在实践TDD时，我们开始体验到“大声疾呼”的现象。 简而言之，创建失败并通过测试的短暂行为将在智力上挑战开发人员。 他们会大声说“我认为这会过去”和“我不认为这会过去”或“我不确定，请尝试这种方法后再考虑。”

The developer’s IDE has become a rubber duck begging for an intense conversation. At a minimum, TDD shops should be humming with this type of conversion.

开发人员的IDE已成为恳求激烈对话的橡皮鸭。 至少，TDD商店应该对这种类型的转换感到很满意。

Think, then speak up about your immediate next move(s).

想一想，然后说说您的下一步行动。

This type of reinforcement is key to communication, not only to predict your next action, but also to reinforce the concepts of writing the simplest code to make a unit test pass. Of course, if the developer becomes silent, they are almost certainly wandering off the loop and must come back on the path.

这种增强功能是沟通的关键，不仅可以预测您的下一个动作，而且可以增强编写最简单代码以通过单元测试的概念。 当然，如果开发人员变得沉默寡言，则几乎可以肯定，他们正在徘徊，必须回到正轨。

2. TDD命令肌肉记忆 (2. TDD Commands Muscle Memory)

As a developer moves forward with the first cycles of TDD, they will experience heavy fatigue by battling through high friction and awkward flow. This is true for any initiated but unlearned human activity. The developer will attempt to find shortcuts to improve the cycle, because the goal is to reduce that awkwardness and to improve muscle memory.

随着开发人员在TDD的第一个周期中向前发展，他们将因高摩擦力和笨拙的流动而遭受严重疲劳。 对于任何发起但未学习的人类活动，都是如此。 开发人员将尝试找到捷径以改善周期，因为目标是减少这种尴尬并改善肌肉记忆。

Muscle memory is a key to feeling the good vibes and becoming fluid. TDD demands it because of execution repetition.

肌肉记忆是感觉良好的共鸣并变得流畅的关键。 TDD由于执行重复而要求它。

Print out a shortcut cheat sheet. Learn only as many shortcuts in your IDE as you need to make your cycles efficient. Then, keep searching for more.

打印出快捷备忘单。 在IDE中，仅需学习尽可能多的快捷方式即可提高循环效率。 然后，继续寻找更多。

The developer will become an expert of select shortcuts only in a matter of a few sittings, including building and running the test rig. With more practice, creating new artifacts, highlighting text, and navigating the IDE will become natural. Finally we graduate to unlock all of the refactor shortcuts such as extraction, renaming, generation, pulling up, reformatting, and pushing down code.

开发人员仅在几个阶段就可以成为选择快捷方式的专家，包括构建和运行测试平台。 通过更多的实践，创建新的工件，突出显示文本以及浏览IDE将变得很自然。 最后，我们毕业以解锁所有重构快捷方式，例如提取，重命名，生成，上拉，重新格式化和下推代码。

3. TDD命令至少略微思考 (3. TDD Commands Thinking At Least Slightly Forward)

Each time a developer sits to start TDD, they must have a concrete short mental map on what is to be solved. In a traditional coding approach, this is not always true, as the mental map of the solve could be macro and exploratory. The developer does not know how to solve the problem, but may know of a fuzzy goal. To get to that goal, unit tests are neglected in the process.

每次开发人员坐下来开始TDD时，他们都必须对要解决的问题有一个具体的简短思路。 在传统的编码方法中，这并不总是正确的，因为求解的思维导图可能是宏大的和探索性的。 开发人员不知道如何解决问题，但可能知道模糊的目标。 为了达到这个目标，在过程中忽略了单元测试。

The start and end of the sitting should also be ritualized. First, think and list. Play with it. List more. Then start, do, and then think. Check off. Repeat some times. Finally think and stop.

开会的开始和结束也应仪式化。 首先，思考并列出。 玩吧。 列出更多。 然后开始，做，然后思考。 检查一下。 重复几次。 最后思考并停止。

Maintain your test list like a hawk. Check off items as you go. Never drive without one. Think!

像鹰一样维护您的测试清单。 随身检查物品。 切勿无人驾驶。 认为！

The list may take some time to formulate and is not a part of the cycle. However it should be prepared right before the cycles start. If you don’t have one, you may not know where you are going. Always have a map.

该列表可能需要一些时间来制定，并且不是周期的一部分。 但是，应在循环开始之前进行准备。 如果您没有，那您​​可能不知道要去哪里。 总是有一张地图。

// A Test List// "" -> does not validate// "a" -> does not validate// "aa" -> validates// "racecar" -> validates// "Racecar" -> validates// print the validation// have a blueberry ale

The developer must command a test list, as described by Kent Beck. The test list allows direction of solving in the next immediate cycles. That test list should always be labored upon and updated moments before the cycles begin. Once the test list is solved minus the last step, the cycle stops on red with a failing test.

开发人员必须命令测试列表 ，如Kent Beck所述。 测试列表允许在下一个立即循环中求解。 周期开始之前，应该始终检查该测试清单并进行更新。 一旦解决了测试清单减去最后一步，测试失败的循环将以红色停止。

4. TDD要求与他人沟通 (4. TDD Demands Communication With Others)

As the above test list is filled out, certain steps may become blocked because the commitment of work was not clear. The developer cannot figure out the test list. Or the reverse. Generating a presumptive test list that has too many guesses about the missing requirement(s). The suggestion is to stop right there.

填写以上测试清单后，由于工作承诺不明确，某些步骤可能会被阻塞。 开发人员无法找出测试列表。 或相反。 生成对遗漏的要求有太多猜测的推定测试列表。 建议是就此停下来。

Driving without TDD will cause implementations of unneeded complexity to occur. Driving with TDD in listless mindlessness is just as dangerous.

没有TDD的驾驶将导致不必要的复杂性实现。 在无精打采的无意识中驾驶TDD也是危险的。

Speak up loudly if the test list has gaps.

如果测试列表有空白，请大声说出来。

In TDD, the developer must understand what to build based on the owner’s picture of the requirement(s) and no more. If the requirement is unclear in context, the test list will start to break down. That break down will require a conversation. Candid conversions can quickly turn into trust and respect. The short feedback loops are now established.

在TDD中，开发人员必须仅根据所有者对需求的了解而了解要构建的内容。 如果在上下文中要求不明确，则测试列表将开始细分。 发生这种情况需要对话。 坦率的转换可以Swift变成信任和尊重。 现在建立了短反馈回路。

5. TDD要求迭代架构 (5. TDD Demands Iterative Architecture)

Initially proposed in the first edition of the XP book, Kent proposed that tests should drive architecture. However, over the course of a few years there have been stories about how sprint teams crash into walls about a few sprints in.

最初在XP本书的第一版中提出，肯特提出测试应该驱动体系结构。 但是，在过去的几年中，有一些关于冲刺团队如何撞入一些冲刺的墙的故事。

Of course, having tests drive all of the architecture is unwise. Uncle Bob had agreed with other experts that architecture driven by tests is “horse sh*t.” [1] Some larger map is required, but not too far above the distributed test lists that are being worked on in the field.

当然，让测试驱动所有架构是不明智的。 鲍勃叔叔已经与其他专家达成一致，认为由测试驱动的体系结构是“马力”。 [1]需要一些较大的地图，但距离现场正在使用的分布式测试列表不远。

Kent also called this out many years ago in the TDD By Example book. Concurrency and security are the two major areas where TDD cannot drive and the developer must be concerned separately. Loosely translated, concurrency via system design is on a different level and must be labored over iteratively and in concert with TDD. This is very true today, as some architectures are driving toward reactive and reactive extensions, the zenith of concurrency construction.

肯特(Kent)在很多年前的《 TDD示例》一书中也提到了这一点。 并发性和安全性是TDD无法驱动的两个主要领域，开发人员必须分开关注。 松散地翻译后，通过系统设计进行的并发处于不同的级别，必须在迭代过程中与TDD协同工作。 今天，这是非常正确的，因为某些体系结构正朝着React式和React式扩展的方向发展，这是并发构建的顶峰。

Create a larger map of organization. A vision that goes just a little bit ahead. Make sure you are steering with the team in the same way.

创建更大的组织结构图。 远超前瞻的愿景。 确保您以相同的方式指导团队。

However, the most important idea is the organization of the system which TDD cannot effectively handle alone. This is because unit tests test at a lower level. Iterative architecture and TDD orchestration is hard in practice and demands trust among all team members, pair programming, and solid code review. There is no clear way to do this, but it will become apparent that short iterative design sessions are needed in unison with the test lists in the field.

但是，最重要的想法是TDD无法单独有效处理的系统组织 。 这是因为单元测试在较低级别进行测试。 迭代体系结构和TDD编排很难实践，并且需要所有团队成员之间的信任，结对编程和可靠的代码审查。 没有明确的方法可以执行此操作，但是很明显，需要与现场的测试列表保持一致的简短迭代设计会话。

6：TDD揭示了单元测试的脆弱性和退化性实施 (6: TDD Reveals Unit Test Frailty And Degenerative Implementation)

Unit tests have a funny property about them and TDD exposes that property. They cannot prove correctness. E.W. Dijkstra had labored over this and discussed the possibility of mathematical proofs in our profession to resolve the gap.

单元测试具有一个有趣的属性，而TDD公开了该属性。 他们无法证明正确性。 EW Dijkstra对此进行了努力，并讨论了在我们的专业领域中通过数学证明来解决这一差距的可能性。

For example, the below solves all tests around a hypothetical imperfect palindrome that business required. It was developed with TDD.

例如，以下内容解决了业务所需的假设不完全回文的所有测试。 它是用TDD开发的。

// Not an imperfect palindrome.

@Testfun `Given "", then it does not validate`() {    "".validate().shouldBeFalse()}@Testfun `Given "a", then it does not validate`() {    "a".validate().shouldBeFalse()}@Testfun `Given "aa", then it validates`() {    "aa".validate().shouldBeTrue()}@Testfun `Given "abba", then it validates`() {    "abba".validate().shouldBeTrue()}@Testfun `Given "racecar", then it validates`() {    "racecar".validate().shouldBeTrue()}@Testfun `Given "Racecar", then it validates`() {    "Racecar".validate().shouldBeTrue()}

Indeed, these tests have holes. Unit tests are frail even for the most trivial asks. We can never prove correctness because if we had to, it would require an extreme mental labor and the required inputs would be unimaginable.

确实，这些测试有漏洞。 即使对于最琐碎的要求，单元测试也很脆弱。 我们永远无法证明正确性，因为如果必须这样做，那将需要极大的脑力劳动，而所需的投入也将是无法想象的。

// Too generic of a solve based on tests provided

fun String.validate() = if (isEmpty() || length == 1) false else toLowerCase() == toLowerCase().reversed()

// Is the best implementation and solves all tests

fun String.validate() = length > 1

length >; 1 could be called degenerative implementation. It is just enough implementation to solve the problem at hand, but on its own tells us nothing about the problem we are trying to solve.

length > ; 1可以称为简并性实施 。 这仅足以解决眼前的问题，但仅凭它自己并不能告诉我们我们要解决的问题。

The question is, when does an developer stop writing the tests? The answer seems to be simple. When the business is satisfied, not when the code author is. This may hurt our construction passion and we are embarrassed by the simplicity. These feelings are balanced by the good feelings of clean code and the ability to refactor with confidence later. Things simply feel tidy and clean.

问题是，开发人员何时停止编写测试？ 答案似乎很简单。 当业务满足时 ，而不是代码作者满意时。 这可能会损害我们的施工热情 我们是 为简单感到尴尬 。 这些感觉被干净代码的良好感觉和以后自信地进行重构的能力所平衡。 东西简直干净利落。

Be aware that the unit tests are fallible but are necessary. Understand their strength and weakness. Mutation testing may help tie up this gap.

请注意，单元测试是容易犯错的，但是必需的。 了解他们的优势和劣势。 变异测试可能有助于弥补这一差距。

TDD has gains, but it can take away building the sand castles we do not need. It is constraint but it allows us to go faster, further and with safety. Perhaps this is what Uncle Bob really meant about being a professional.

TDD有所收获，但可以带走我们不需要的沙堡。 这是有限制的，但它使我们可以更快，更安全地前进。 也许这就是鲍伯叔叔对成为专业人士的真正含义。

But! No matter how frail unit tests may seem, they are a core necessity. They are required to allow fear to turn into courage. Tests allow those to mercifully refactor the code and even better, it is a guide, a documentation, for any other developer to immediately jump in and being to add value to a project that is well supported by unit testing.

但！ 不管看起来多么脆弱的单元测试，它们都是核心必要条件。 他们必须让恐惧变成勇气 。 测试允许那些人认真地重构代码，甚至更好，它是指南， 文档 ，任何其他开发人员都可以立即参与并为由单元测试很好地支持的项目增加价值。

7：TDD显示断言完成反馈环 (7: TDD Reveals Assertion Completion Feedback Loop)

Take a step back further. For the next two phenomena, we will visit strange re-occurrences. For the first occurrence, let’s take a quick look at FizzBuzz. Here is our test list.

向后退一步。 对于接下来的两种现象，我们将进行奇怪的重现。 对于第一次出现的情况，让我们快速看一下FizzBu​​zz。 这是我们的测试清单。

// Print numbers 9 to 15. [OK]// For numbers divisible by 3, print Fizz instead of the number.// ...

We are a few steps in. We now have a failing test.

我们已经介入了一些步骤。我们现在测试失败。

@Testfun `Given numbers, replace those divisible by 3 with "Fizz"`() {    val machine = FizzBuzz()    assertEquals(machine.print(), "?")}class FizzBuzz {    fun print(): String {        var output = ""        for (i in 9..15) {            output += if (i % 3 == 0) {                "Fizz "            } else "${i} "        }        return output.trim()    }}

Expected , actual .

Naturally, if we duplicate the expected assertion data to assertEquals, it achieves the result and the test passes.

自然地，如果我们将期望的断言数据复制到assertEquals ，它将获得结果并通过测试。

As we keep querying the test rig during implementation steps, failing unit tests set around data may correctly answer their own assertions. Perhaps we can call this voodoo testing.

当我们在实施步骤中不断查询测试平台时，围绕数据设置的单元测试失败可能会正确回答他们自己的断言。 也许我们可以称之为伏都教测试。

Sometimes failing tests will scream a correct result that is required to make the test pass. I do not know what to call these events… perhaps voodoo testing. Your milage may vary based on your laziness and test etiquette, but I have seen this happen numerous times when working to have implementation achieve canned and expected data sets.

有时，失败的测试会尖叫出通过测试所需的正确结果。 我不知道该如何称呼这些事件……也许是伏都教测试 。 您的工作量可能会因您的懒惰和测试礼节而有所不同，但是我发现，在实现实现固定和预期的数据集的过程中，这种情况屡屡发生。

8：TDD揭示了转型优先前提 (8: TDD Reveals The Transformation Priority Premise)

In TDD, one can become trapped. There are situations where the developer can be entangled by the transformations they apply to achieve implementation. At some point, the testing code becomes a bottle neck to move forward. An impasse forms. The developer has to back out, and disarm by removing a portion of tests to get out of the hole. The developer becomes exposed.

在TDD中，可能会陷入困境。 在某些情况下，开发人员可能会纠缠于他们为实现实现而进行的转换。 在某些时候，测试代码成为前进的瓶颈。 僵局形成。 开发人员必须退出，并通过移除一部分测试来摆脱困境，从而解除武装。 显影剂暴露出来。

Uncle Bob likely has experienced these impasses in his career, and then he probably realized that the act of making a test pass must require a preferred order so that the risk of a impasse is reduced. At the same time, he also would’ve realized a premise. As the tests get more specific, the code gets more generic.

鲍伯叔叔可能在他的职业生涯中经历了这些僵局，然后他可能意识到进行测试合格的行为必须要求优先下达命令，以减少陷入僵局的风险。 同时，他也将意识到一个前提。 随着测试变得更加具体，代码变得更加通用。

This is called the Transformation Priority Premise. There seems to be an order of refactor risk one can chose to achieve by passing a test. The top transformation chosen (the simplest) is usually the best option and will incur the least risk to create a situation of an impasse.

这称为“ 转换优先级前提” 。 人们似乎可以选择通过测试来实现重构风险的顺序。 选择的最高转换(最简单)通常是最佳选择，并且制造陷入僵局的风险最小。

TPP or perhaps Uncle Bob’s Test Calculus is one of the most intriguing, technical, and exciting observations to date. Use it as a guide to keep the code as simple as possible.

TPP 也许 鲍伯叔叔的考试演算 是 迄今为止最有趣，技术和最令人兴奋的观察之一。 用它作为指导，使代码尽可能简单。

Print out the TPP list and place it at your desk. Refer to it as you drive to avoid impasses. Embrace an order of simplicity.

打印出TPP列表并将其放在您的办公桌上。 开车时请参考，以免陷入僵局。 接受简单的命令。

This completes all initial observations. But before we conclude, I’d like to get back to my original unanswered question “How many or what percentage of software professionals use TDD today?” My answer stands at “I think the group is small”. I’d like to explore this guess below with reasons why.

这样就完成了所有初始观察。 但是，在得出结论之前，我想回到我最初的未回答的问题：“今天有多少软件专业人员使用TDD？ 我的回答是“我认为这个小组很小”。 我想在下面探讨这种猜测以及原因。

TDD起飞了吗？ (Has TDD Taken Off?)

Unfortunately it hasn’t. The percentage is subjectively low and the search for data continues. Taking from my experiencing in hiring, leading teams, and being an empathic developer myself, let me rely my observations.

不幸的是，事实并非如此。 该百分比主观上较低，并且继续搜索数据。 从我在招聘，领导团队方面的经验以及我自己成为一个善解人意的开发人员的经验中，我可以依靠我的观察。

原因1：没有暴露于真实的测试文化 (Reason 1: No Exposure To Real Testing Culture)

My educated guess is that a majority of software developers have not had the experience of learning and working through a testing culture.

我的有根据的猜测是，大多数软件开发人员都没有在测试文化中学习和工作的经验。

The definition of a testing culture is a place where developers are deliberately practicing and improving by testing. They are continuously mentoring those who are not skilled in the area. Each pairing and in every pull request is a feedback loop on building individuals to become great at testing. There is also major support and backing all the way up the engineering chain. All managers understand and believe in testing. When deadlines and times get tough, the test discipline is not dropped — it is maintained.

测试文化的定义是开发人员有意通过测试进行实践和改进的地方。 他们一直在指导那些不熟悉该领域的人。 每个配对和每个拉取请求中都有一个反馈循环，用于建立个人以使其在测试中变得出色。 在整个工程链中也有大量的支持和支持。 所有经理都理解并相信测试。 当截止日期和时间变得艰难时，测试纪律就不会消失-它得到维护。

Those that have gone through a testing culture, like myself, are lucky to have those observations. We can apply the experience to future projects.

那些像我这样经历过测试文化的人很幸运能够得到这些观察。 我们可以将经验应用于未来的项目。

原因2：教育资源不明确 (Reason 2: Unclear Educational Resources)

Some have attempted to write books on the subject such as xUnit Patterns and Effective Unit Testing. However, there seems to be no place that clearly defines what and why to test. Most resources out there do not clearly describe the craft of assertion and verification.

有些人试图编写有关该主题的书籍，例如xUnit模式和有效的单元测试 。 但是，似乎没有地方明确定义要测试的内容和原因。 那里的大多数资源都没有清楚地描述断言和验证的技巧。

Open source projects are also hit or miss with good unit tests. In these unfamiliar projects, the very first thing I do is look for tests. My disappointment is almost certain. I can also remember the very few instances of excitement when tests are present but also… readable.

良好的单元测试也会对开源项目造成打击。 在这些陌生的项目中，我要做的第一件事就是寻找测试。 我的失望几乎可以肯定。 我还记得当测试存在但也很可读时，很少有兴奋的例子。

原因3：大学没有重点 (Reason 3: No Focus In Universities)

My observation of candidates over the years fresh out of university reveals a well-known assumption: little to no discipline in testing rigor. Every developer I know has learned testing afterward, some on their own but most going through a previous testing culture experience.

我对刚从大学毕业的那些年的候选人的观察揭示了一个众所周知的假设：测试严格性几乎没有学科。 我认识的每个开发人员都是后来学习测试的，其中一些是自己开发的，但大多数经历过以前的测试文化经验。

原因4：要求具有高测试热情的职业 (Reason 4: A Career Of High Test Passion Required)

It also takes passion to be interested in testing and to understand the details and benefits over a large time period. You have to be hungry and obsess on clean code and doing the craft better.

对测试感兴趣并了解大量时间的详细信息和好处也需要热情。 您必须饥肠ob，执着于干净的代码，并且要精通手艺。

Most just want to get things working, achieving only half of what Kent Beck said “First make it work, then make it right.” I empathize that to get things working is a tough battle in itself.

大多数人只是想让事情顺利进行，而只实现了肯特·贝克所说的一半：“首先使之工作，然后再使其正确。” 我很同情让事情顺利进行本身就是一场艰苦的战斗。

Testing is just as hard to do well, so let’s conclude on that thought.

测试很难很好地完成，所以让我们总结一下这个想法。

结论 (Conclusion)

Kent’s proposal in XP included a simple formulation of instinct, thought, and experience. These three levels are stepping stones to execution quality measured by a threshold. This is a great model to explain a problem with TDD.

肯特(Kent)在XP中的建议包括对本能 ， 思想和经验的简单表述。 这三个级别是通过阈值衡量的执行质量的基础。 这是解释TDD问题的好模型。

The threshold for clean test execution is high, in that it eclipses a generous baseline of experience. The majority will never become above water and those that do are lucky — have experience from the elusive testing culture.

干净测试执行的门槛很高，因为它掩盖了丰富的经验基础。 绝大多数人将永远无法幸免，而那些幸运的人将拥有难以捉摸的测试文化中的经验。

Software is tough enough to build and organize, but testing takes it to a whole new level of enlightenment.

软件足够强大，难以构建和组织，但是测试将其带入了一个全新的启发水平。

Early on, I had an instinct that testing is important, but my test culture experience came later. It took years of thought in my career, but without that experience of test culture, I would have not emerged above that threshold.

早期，我本能地认为测试很重要，但是后来我的测试文化经验来了。 在我的职业生涯中花了多年的时间思考 ，但是如果没有那种测试文化的经验，我将不会超越这个门槛。

I believe that many developers also have this thought but cannot see the true benefit of test culture due to lack of specific experience.

我相信许多开发人员也有这种想法，但由于缺乏特定经验，因此无法看到测试文化的真正好处。

TDD discipline has struggled to take off due in part to high learning curve of testing. Even armed with veteran testing knowledge and experience, TDD requires a headspace that is unique and challenging. However, all should try it.

TDD学科很难起步，部分原因在于测试的高学习曲线。 即使拥有经验丰富的测试知识和经验，TDD仍需要一个独特且具有挑战性的顶空。 但是，所有人都应该尝试一下。

Amplify this. TDD demands all that thought and experience and more. It is not easy and is a skill. I think it is because it commands the developers throughput to the maximum, continuously and relentlessly. We are all vulnerable in the process, and few developers like being in this position.

放大这个。 TDD需要所有的思想和经验 还有更多。 这不容易，是一种技能。 我认为这是因为它连续不断地命令开发人员获得最大的吞吐量。 我们在此过程中都很脆弱 ，很少有开发人员喜欢担任这一职位。

@Testfun `Given software, when we build, then we expect tests`() {    build(software) shoudHave tests}

However, TDD is an intriguing discipline and is a tool to lean on. Its phenomena should be studied in detail. If anything else, the discipline makes for better developers as the practice contains benefits which can strengthen the individual and collective group.

但是，TDD是一门有趣的学科，并且是可以依靠的工具 。 应详细研究其现象 。 如果有什么其他要求，该学科可以为更好的开发人员提供帮助，因为该实践所包含的好处可以增强个人和集体的利益。

Inspiration for this post was due in part by Danny Preussler. As I re-explore the discipline, he has started running comprehensive Android TDD workshops. Check out his recent deck here.

这篇文章的灵感部分来自丹尼•普勒斯勒 ( Danny Preussler) 。 当我重新研究该学科时，他已经开始运行全面的Android TDD研讨会。 在这里查看他最近的卡座 。

[1] Jim Coplien and Bob Martin Debate TDD

[1] Jim Coplien和Bob Martin Debate TDD

翻译自: https://www.freecodecamp.org/news/8-observations-on-test-driven-development-a9b5144f868/

测试驱动开发 测试前移