tdd测试驱动开发课程介绍

by Luca Piccinelli

通过卢卡·皮奇内利

测试驱动开发很难！ 这是不为人知的事实。 (Test Driven Development is hard! This is the untold truth about it.)

These days you read a ton of articles about all the advantages of doing Test Driven Development (TDD). And you probably hear a lot of talks at tech conferences that tell you to “Do the tests!”, and how cool it is to do them.

这些天，您阅读了大量有关测试驱动开发(TDD)的所有优点的文章。 而且您可能会在技术会议上听到很多演讲，告诉您“做测试！”，以及进行这些测试有多酷。

And you know what? Unfortunately, they are right (not necessarily about the “cool” part, but about the useful part). Tests are a MUST! The typical advantages we list when it comes to talking about TDD are real:

你知道吗？ 不幸的是，它们是正确的(不一定与“酷”部分有关，而与有用部分有关)。 测试是必须的 ！ 在谈到TDD时，我们列出的典型优势是真实的：

• You write better software
  您编写更好的软件
• You have protection from breaking the world when new features are introduced
  引入新功能后，您可以免受破坏
• Your software is self documented
  您的软件是自我记录的
• You avoid over-engineering
  避免过度设计

Even if I’ve always agreed with these advantages, there was a time when I thought that I didn’t need TDD to write good and maintainable software. Of course, now I know I was wrong, but why did I have this idea despite the shiny magic of the pros? The reason is just one: and let me ask Rihanna to say it for me…

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

成本！ (The Cost!)

It costs a lot! Probably someone is thinking “but it costs even more if you don’t do the tests” — and this is right, too. But these two costs come at different times:

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

• you do TDD ➡ you have a cost now.

  你做TDD➡现在就要花钱了 。

• You don’t do TDD ➡ you will have a cost in the future.

  您不做TDD➡ 将来会付出代价的 。

So, how do we come out of this impasse?

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

The most effective way to get something done is doing it as naturally as possible. The nature of people is to be lazy (here software developers are the best performers) and greedy, so you have to find your way of reducing the costs now. It’s easy to say, but so hard to do!

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

Here I will share my experience and what has worked for me in turning the benefit/cost ratio to my favour.

在这里，我将分享我的经验以及为我带来利益/成本比率方面的成功经验。

But before I do that, let’s analyze some typical difficulties in applying TDD.

但是在我这样做之前，让我们分析一下应用TDD的一些典型困难。

您可以测试两个数字的和吗？ (Are you able to test the sum of two numbers?)

Generally speaking, theory is not optional; you have to master it in order to master the practice. However trying to apply at once all the theoretical knowledge you’ve previously acquired could have the following effect:

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

The typical theory lesson on TDD starts with something like this:

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

And here you are like

在这里你就像

Then comes this:

然后是这样的：

• red ➡ green ➡ refactor cycle
  红色➡绿色➡重构周期
• unit, acceptance, regression, integration tests
  单元，验收，回归，集成测试
• mocking, stubs, fakes
  嘲笑，存根，假货
• if you are lucky (or maybe unlucky ?), someone will tell you about contract testing
  如果您很幸运(或者可能很不幸？)，有人会告诉您有关合同测试的信息
• and if you are very lucky (or maybe very unlucky ?) you will touch legacy codebase refactoring
  如果您很幸运(或者可能很不幸？)，那么您将接触到遗留的代码库重构。

The going gets tough, but you are an experienced developer and all these concepts are not that hard to handle for you. Then class ends; you go home, and throughout the next days you diligently do some code katas to fix the concepts just learned. So far so good.

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

挣扎是真的 (The struggle is real)

Next comes a real world project, with real deadlines and real timing costs — but you are motivated to apply your shiny new TDD. You start thinking about the architecture of your software and start writing tests for the first class and the class itself — let’s call it Class1.

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

Now you think about the first user of Class1, let’s call it UsageOfAClass, and again you test and write it. Class1 is a collaborator of UsageOfAClass, so are you going to mock it? Ok let’s mock it. But what about real interactions of Class1 and UsageOfAClass? Maybe you should test them all as well? Let’s do it.

现在，您考虑Class1的第一个用户，我们称它为UsageOfAClass，然后再次测试并编写它。 Class1是UsageOfAClass的合作者，所以您要模拟它吗？ 好吧，让我们模拟一下。 但是，Class1和UsageOfAClass的真实交互又如何呢？ 也许您也应该对它们全部进行测试？ 我们开始做吧。

At this point, inside of you, you start hearing a little voice that says “I would develop much faster if I didn’t have to write these tests…”. You don’t listen to this evil voice and proceed straight to the next test.

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

Class2 is going to be used by UsageOfAClass and it persists itself inside a Db. So, do we have to test Class2, its interaction with UsageOfAClass, and the persistence in the Db? But wait… did anyone mention how to cope with I/O testing during the TDD theory class?

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

The theory behind TDD is not that hard to understand, but applying it to the real world can be really complex if you don’t approach it the right way.

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

去做就对了 (Just do it)

We should always keep in mind that theory must be bent to our needs and not the contrary.

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

The main goal is to get the job done. So my advice is, just do it!

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

Start simple and just do your task up to the end. Then, when you get stuck in some theoretical mind loop like:

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

• is this a unit or an integration test?
  这是单元测试还是集成测试？
• here should I mock it or not?
  我应该在这里嘲笑吗？
• oh crap, here I should write a new collaborator, so a brand new suite of infinite unit tests just to write “hey, banana”…
  糟糕，这里我应该写一个新的协作者，因此，一套全新的无限单元测试套件只是写了“嘿，香蕉”……

just forget about theory for a while and take a step forward. Just do it as it comes!

只是暂时忘记理论并向前迈进。 只要做到就行！

Once you are done with your task, have a look back at your work. Looking back at the completed job, it will be much easier to analyze what would have been the right thing to do.

完成任务后，请回顾一下您的工作。 回顾完成的工作，将更容易分析什么是正确的事情。

实用TDD (Practical TDD)

Just do it. By the way, I think this is also the right approach to TDD.

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

What was wrong in how we built Class1, Class2 and UsageOfAClass? The approach.

我们如何构建Class1，Class2和UsageOfAClass出了什么问题？ 该方法。

This is a bottom-up approach:

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

• analyze the problem
  分析问题
• figure out an architecture
  弄清楚一种架构
• start building it from unit components
  从单元组件开始构建

This approach is the best friend of over-engineering. You typically build the system in order to prevent changes that you think will come in the future, without knowing if they actually will. Then when some requirement changes, it typically happens in a way that doesn’t fit your structure, no matter how good it is.

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

For me the key to drastically reducing the immediate cost of writing with TDD has been to take a top-down approach:

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

1. bring a user story
   带来用户故事
2. write a very simple test of a use case
   编写一个非常简单的用例测试
3. make it run
   使它运行
4. go back to step 2 until all use cases are complete
   返回第2步，直到所有用例都完成为止

While doing this process, don’t worry too much about architecture, clean code (well, remember at least to use decent variables names) or any kind of complication that is not currently needed. Just do what you know you need now, up to the end.

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

Tests of the story clearly state what are the current and known requirements.

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

Once you are done, take a look at your big ball of spaghetti mud code, get over the shame, and look deeper at what you have done:

完成后，看看您的意大利面条泥代码大团子，摆脱羞耻，然后更深入地了解已完成的工作：

• it works! And tests prove it.
  有用！ 测试证明了这一点。

• All the system is there, and just what is actually needed to get the job done.

  所有的系统都在那里， 而完成工作实际上需要什么 。

Now you have an overview of all the parts of your system, so you can refactor with the knowledge of the domain that you couldn’t have had when you started from scratch. And tests will make sure that nothing will break while refactoring.

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

重构 (Refactoring)

The best way for me to start to refactor is to identify areas of responsibility and separate them in private methods. This step helps identify responsibilities and their inputs and outputs.

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

After that, classes of collaborators are almost there and you just need to move them into different files.

在那之后，协作者的类别几乎已经存在，您只需要将它们移到不同的文件中即可。

As you proceed, first write tests for the classes that pop out from the process and iterate until you are satisfied with the result. And remember, if you get stuck somewhere, just do it! If you do something bad, once you are done you will have more information on how to get over the mistake the next time you face it. Getting the job done is the priority, to the best of your current abilities.

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

This way, if you analyze your errors to learn from them, you will also refine your abilities.

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

下一个用户故事 (The next user story)

Continue developing your product following these steps:

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

• take a story
  讲一个故事
• make it work completely in a “test — code” cycle.
  使其完全在“测试-代码”循环中工作。
• refactor
  重构

While adding features you will continue to change your software and maybe even its structure. But as the system grows, the cost of change will maintain a linear growth thanks to the two main features of TDD:

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

• architecture discovery (that helps to control the complexity)
  架构发现(有助于控制复杂性)
• protection from breaking changes
  保护免受重大更改

The system will not be over-engineered, as architecture is going to emerge as stories get completed. You don’t think about what could be future requirements; if you end up needing it, then the cost to implement it will be low.

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

有什么可能使它出错？ (What can make it go wrong?)

The size of the story. What you build up to the end must be the right size. Not too big (otherwise it will take too much time to get any feedback) or too small (otherwise you won’t have the overview).

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

What if the story is too big? Split it up in pieces that can be built from the start to the end.

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

下一步是什么？ (What’s next?)

In the next article I will give a practical example of the concepts I explained here. We will implement, step by step, the Bowling Game kata starting from an acceptance test.

在下一篇文章中，我将给出在此说明的概念的实际示例。 我们将从验收测试开始逐步实施保龄球游戏kata 。

It is not a real world problem, but it has enough complexity to see how TDD can help in handling it.

这不是一个现实世界的问题，但是它具有足够的复杂性，可以了解TDD如何帮助处理它。

Please share your opinion and suggestions about this article. Do you agree with me or do you think that all this is a bunch of rubbish? Let me know what you think in comments; it would be very nice to start a conversation on TDD and share our experiences.

请分享您对本文的看法和建议。 您是否同意我的观点，或者您认为这都是一堆垃圾？ 让我知道您在评论中的想法； 最好在TDD上进行对话并分享我们的经验。

I want to thank Matteo Baglini for helping me to find my way through a practical approach to software development and TDD.

我要感谢Matteo Baglini帮助我通过一种实用的软件开发和TDD方法找到了自己的出路。

Thank you for reading!

感谢您的阅读！

Cover image courtesy of testsigma.

封面图片由testigma提供 。

翻译自: https://www.freecodecamp.org/news/practical-tdd-test-driven-development-84a32044ed0b/

tdd测试驱动开发课程介绍