采用tdd实现计算器
Test-Driven Development is a game-changing methodology for any software project with a life span more extensive than one year; unfortunately, many developers and companies fail to embrace it. In the first instance, it might seem a problem of developer skills and lack of self-discipline, but it is not. You cannot enforce TDD on your team, it does not work this way, but if you overcome the key challenges, you will successfully adopt it.
测试驱动开发是一种改变生命的方法论，适用于任何寿命超过一年的软件项目。 不幸的是，许多开发人员和公司未能接受它。 首先，这似乎是开发人员技能和缺乏自律的问题，但事实并非如此。 您不能在团队中强制执行TDD，它不能以这种方式工作，但是如果您克服了关键挑战，您将成功采用它。
两队的故事 (The story of two teams)
Once upon a time ago, two teams worked in the same project but different repositories: the Antelope team and the Beaver team. The Antelope team decided to start with TDD from the first day; the beginning was hard, but instead of enforcing what they thought that TDD was, they kept learning and looking for better ways to improve their tests. They bend TDD until it fitted in their needs. The Beaver team also started with TDD, it also was hard, but they tried to be strict and follow what they understood that TDD was. Although the team had a strong will and tried and tried embracing TDD, their tests became almost useless, and their TDD almost unexisting.
从前，两个团队在同一个项目中工作，但存储库不同：羚羊团队和海狸团队。 羚羊小组决定从第一天开始使用TDD。 起初很艰难，但是他们没有坚持自己认为TDD是什么，而是继续学习并寻找改善测试的更好方法。 他们弯曲TDD，直到它满足他们的需求。 Beaver团队也从TDD开始，这也很艰难，但是他们试图变得严格，并遵循他们对TDD的理解。 尽管团队有坚强的意志，并且尝试了尝试使用TDD，但是他们的测试几乎变得毫无用处，并且他们的TDD几乎不存在。
Two years later, a new member without TDD experience and equally skilled entered into each team. They were Alice and Bob. Alice joined the Antelope team; Bob joined the Beaver team. One month later, Alice was successfully practicing TDD. Six months later, Bob was still struggling with tests and failing to adopt TDD.
两年后，一个没有TDD经验和同等技能的新成员加入了每个团队。 他们是爱丽丝和鲍勃。 爱丽丝加入了羚羊队。 鲍勃加入了海狸队。 一个月后，爱丽丝成功地练习了TDD。 六个月后，Bob仍在努力进行测试，未能采用TDD。
TDD是一个完整的团队承诺 (TDD is a full team commitment)
When a team fails to implement TDD, it starts with individual pitfalls, but it ends with a full team failure. The whole team must practice TDD during all times without exceptions. If one, or more than one, members fail to practice TDD at all times, the entire team will eventually stop doing TDD.
当团队无法实施TDD时，它会从单个陷阱开始，但最终会导致团队完全失败。 整个团队必须始终无时无刻地练习TDD。 如果一个或多个成员始终没有练习TDD，则整个团队最终将停止执行TDD。
According to the Agile Alliance (see here), some of the most common reasons a team member fails to apply TDD are: not running tests frequently and writing too many tests at once. It also states that if there is a partial adoption, the team will fail to adopt TDD.
根据敏捷联盟(请参阅此处 )，团队成员未能应用TDD的最常见原因有：不频繁运行测试并一次编写太多测试。 它还指出，如果部分采用，则团队将无法采用TDD。
If there is a partial adoption of TDD, the whole team will fail to adopt TDD.
如果部分采用TDD，则整个团队将无法采用TDD。
TDD is a full team commitment. If one or more group members fail to practice TDD correctly, not only will they affect the work they do, but they will also affect the work their peers do. When these members fail to implement TDD because of any of the aforesaid individual reasons, they will create obstacles that will prevent their peers from following TDD practices. It will start a chain of successes that will damage TDD on that team severely. But why?
TDD是一个完整的团队承诺。 如果一个或多个小组成员未能正确地实践TDD，则不仅会影响他们所做的工作，而且还会影响其同龄人所做的工作。 当这些成员由于上述任何个人原因而未能实施TDD时，他们将制造障碍，阻止其同行遵循TDD做法。 这将开始一系列成功，这将严重损害该团队的TDD。 但为什么？
它是指导开发人员的源代码。 (It is the source code that guides developers.)
Did you have stopped to think about why Alice learned TDD in just one month? Did you have considered that it was because their colleagues helped her? Or there was another reason?
您是否已停止思考为什么爱丽丝在短短一个月内学会了TDD？ 您是否认为这是因为他们的同事帮助了她？ 还是还有其他原因？
The source code contains more than the implementation of your product; it contains millions of microdecisions from the developers that have contributed to it. Each decision represents one strategy and one direction; the sum of all defines the least resistance path.
源代码不仅包含产品的实现，还包含其他内容。 它包含做出贡献的开发人员的数百万个微决策。 每个决定代表一个策略和一个方向； 总数之和定义了最小的阻力路径。
When a new developer joins a team, the first thing that he has to do is to read the code. He needs to understand how it works and how he can introduce or fix new features. And the primary technique used, for both new and old developers, is the copy-paste. When any developer needs to implement a new feature, the first thing he does is look for similar code and copy-paste it.
当新开发人员加入团队时，他要做的第一件事就是阅读代码。 他需要了解它的工作原理以及如何引入或修复新功能。 对于新老开发人员而言，使用的主要技术是复制粘贴。 当任何开发人员需要实现新功能时，他要做的第一件事就是寻找相似的代码并将其复制粘贴。
Imagine that you have to implement a new feature and because you are doing TDD, you have to start with a test. Which would be your first step if you have a large codebase? Without any doubt, you will look for an existing test similar to what you need, and you will copy-paste it. If your tests are clean, it will become easy: with few tweaks, it will work quickly. If you spend a little more time creating common abstractions in those tests, it will keep being easy next time.
想象一下，您必须实现一项新功能，并且由于正在执行TDD，因此必须从测试开始。 如果您的代码库很大，哪一步是您的第一步？ 毫无疑问，您将寻找与您需要的测试类似的现有测试，并将其复制粘贴。 如果您的测试是干净的，它将变得很容易：只需进行少量调整，即可快速运行。 如果您花更多的时间在那些测试中创建通用抽象，那么下一次它将变得很容易。
The source code is the most valuable member of your team.
源代码是团队中最有价值的成员。
Why was Alice able to embrace TDD in just one month? Because the source code assisted her. The source code has more value than the implementation of your product: it is the most valuable member of your team. And you should invest in it consequently.
为什么爱丽丝在短短一个月内就能接受TDD？ 因为源代码帮助了她。 源代码比产品的实现更具价值：它是团队中最有价值的成员。 因此，您应该对其进行投资。
手动测试：敌人编号1。 (Manual testing: Enemy number 1.)
We all agree that manual testing is one of the more expensive and risky practices. From the QA point of view, it is costly to manually run all the test each time you release the product; it usually translates in reducing the number of tests, taking some risks, and do only the minimum number of tests. That is why most QA teams have an objective to automatize those tests. They are the only guarantee to keep the price low while adding more tests. Do a test manually, and you will have to repeat in the next release; write an automatic test, and you will able to rerun it in each release almost for free.
我们都同意手动测试是较昂贵且风险较大的做法之一。 从质量检查的角度来看，每次发布产品时手动运行所有测试的成本很高； 它通常意味着减少测试次数，承担一些风险，并且仅执行最小数量的测试。 这就是为什么大多数质量检查团队都有一个目标，可以使这些测试自动化。 它们是在添加更多测试的同时保持价格低廉的唯一保证。 手动进行测试，您将不得不在下一个版本中重复进行； 编写一个自动测试，您几乎可以在每个版本中重新运行它。
But manual testing goes beyond QA: developers are continuously testing your product while they build it. Without TDD and automatic testing for developers, each time that the developer makes a change in the code, he restarts the application, navigates screens, inputs data, and checks results. It takes time, and he has to repeat these steps many times. It is expensive, but the problem is even more severe.
但是，手动测试超出了质量检查范围：开发人员在构建产品时不断对其进行测试。 在没有TDD和对开发人员的自动测试的情况下，开发人员每次更改代码时，都会重新启动应用程序，浏览屏幕，输入数据并检查结果。 这需要时间，他不得不重复这些步骤很多次。 它很昂贵，但问题更加严重。
According to TDD mainstream, if developers test manually while coding, the quality of the tests plummets. There are two reasons: first, automatic tests are pointless for them because they know that the code works, but second, and more importantly, you cannot know if tests work correctly. Making the code pass a failing test is how we check that tests work correctly.
根据TDD主流的说法，如果开发人员在编码时手动进行测试，则测试质量将直线下降。 原因有两个：首先，自动测试对他们毫无意义，因为它们知道代码可以正常工作，但是其次，更重要的是，您不知道测试是否正常工作。 使代码通过失败的测试是我们检查测试是否正常工作的方式。
If you want to succeed with TDD, remove all needs for manual testing.
如果要成功使用TDD，请删除所有手动测试需求。
And this drop in quality for tests will unquestionably affect your team practices. Manual testing is the greatest enemy of TDD. Once we start doing manual testing, we kill TDD. If you want to succeed with TDD, remove all needs for manual testing.
测试质量的下降无疑会影响您的团队实践。 手动测试是TDD的最大敌人。 一旦开始进行手动测试，我们将杀死TDD。 如果要成功使用TDD，请删除所有手动测试需求。
单元测试：敌人2。 (Unit Tests: Enemy number 2.)
We, as an industry, have a problem: Unit Tests. According to the traditional QA semantics, a Unit Test is a test whose failure implicates one and only one unit. For example, if we are designing a car that requires a feature to light the street turning on a switch, we will need at least four units: a battery, a switch, a lamp, and a light bulb. And four unit tests, one to check that the battery provides energy, another one to test that the switch works, another one that shows that the lamp can pass electricity to the lightbulb, and finally the last one that shows that the lightbulb works.
作为一个行业，我们有一个问题：单元测试。 根据传统的QA语义，“单元测试”是指其故障仅涉及一个单元的测试。 例如，如果我们设计的汽车需要具有通过开关打开街道照明的功能，则我们至少需要四个单元：电池，开关，灯和灯泡。 进行了四个单元测试，一个用于检查电池是否供电，另一个用于测试开关是否工作，另一个表明灯可以将电传递给灯泡，最后一个表明灯泡可以工作。
The problem is that none of these tests gives you confidence that the feature will work. What if the battery has the wrong voltage? What if the lightbulb does not fit the battery? You cannot ensure that unless you start integrating units. And if you do that, you are breaking the rule that one failure implicates one and only one unit. But, if the developer only creates unit tests, how the developer knows that the feature is working correctly?
问题在于，这些测试均无法使您确信该功能可以正常工作。 如果电池电压错误怎么办？ 如果灯泡不适合电池怎么办？ 您不能确保除非开始集成单元。 而且，如果这样做，您将违反一个失败规则，即一个故障仅涉及一个单元。 但是，如果开发人员仅创建单元测试，开发人员如何知道该功能正常工作？
With unit tests, the developer needs to test the application manually. Only running the application will know that all units work together correctly. And this will break TDD.
对于单元测试，开发人员需要手动测试应用程序。 只有运行该应用程序才能知道所有单元都可以正常工作。 这将破坏TDD。
What is the alternative? Is it making integrated tests only? Oh no. That is not the solution. Fully integrated tests are necessary for QA and know that everything works correctly, but they are too slow for the developer. With TDD, the developer runs tens, or hundreds, of times the tests in each step; that creates the virtuous circle that gives so much value to TDD. But fully integrated tests are slow; instead of executing one or less milliseconds, each test takes seconds or even minutes. They take too slow for TDD.
有什么选择？ 它仅在进行集成测试吗？ 不好了。 那不是解决方案。 全面集成的测试对于质量检查来说是必需的，并且知道一切正常，但是对于开发人员来说太慢了。 使用TDD，开发人员在每个步骤中运行数十或数百次测试。 形成了良性循环，为TDD带来了巨大价值。 但是完全集成的测试很慢。 而不是执行一个或更少的毫秒，每个测试需要几秒钟甚至几分钟。 对于TDD，它们花费的时间太慢。
The alternative is developer tests. Ward Cunninghan, the precursor of Test Runners, XP, and TDD, explains it in his wiki:
替代方法是开发人员测试。 测试赛跑者，XP和TDD的前身Ward Cunninghan在他的Wiki中对此进行了解释：
A DeveloperTest is the correct name for what the industry generally calls a UnitTest. […] TestDrivenDevelopment produces DeveloperTests. The failure of a test case implicates only the developer’s most recent edit. This implies that developers don’t need to use MockObjects to split all their code up into testable units. And it implies a developer may always avoid debugging by reverting that last edit.
DeveloperTest是业界通常称为UnitTest的正确名称。 [ … ] TestDrivenDevelopment产生DeveloperTest 。 测试用例的失败仅意味着开发人员的最新编辑。 这意味着开发人员不需要使用MockObject将所有代码拆分为可测试的单元。 这意味着开发人员可能总是会通过还原最后的编辑来避免调试。
With developer tests, the developer does not need to run the application manually.
通过开发人员测试，开发人员无需手动运行应用程序。
What is a developer test? If we return to the car factory example and the light feature, the developer test would be: get the headlamp, a light bulb, a battery, a light switch, interconnect them. Turn the switch on. The test passes if the light bulb emits light. It runs fast, in the order of milliseconds, and now the developer does not need to run the application manually to know that everything works together.
什么是开发人员测试？ 如果我们回到汽车工厂的示例和照明功能，则开发人员测试将是：获取前照灯，灯泡，电池，照明开关，并将它们互连。 打开开关。 如果灯泡发光，则测试通过。 它以毫秒为单位的速度运行很快，现在，开发人员无需手动运行应用程序即可知道所有功能都可以一起工作。
行动1：投资测试 (Action 1: Invests in your tests)
To invest in your tests is the most obvious task that you have to perform to achieve TDD successfully. We are talking of TDD, Test-Driven Development, your tests drive your development, literally. The better your tests are, the better your product is.
投资测试是成功实现TDD所必须执行的最明显的任务。 我们所说的是TDD，即测试驱动的开发，实际上，您的测试驱动了您的开发。 测试越好，产品越好。
On the one hand, you need to create rich tests because you need to avoid manual testing at all costs. When the developer needs to execute the application manually to check that he is advancing correctly, you have lost the game of TDD. Make sure that your developers are creating tests good enough to avoid manual testing.
一方面，您需要创建丰富的测试，因为您需要不惜一切代价避免手动测试。 当开发人员需要手动执行该应用程序以检查其是否正确前进时，您就失去了TDD的游戏。 确保您的开发人员创建的测试足够好，以避免手动测试。
On the other hand, you need to maintain your testing code. Your testing code should have the same or better quality than the production code. Do not hesitate to create abstractions, tools, and many components as you need to make your tests easy to maintain and easy to read.
另一方面，您需要维护测试代码。 您的测试代码应具有与生产代码相同或更好的质量。 不要犹豫创建抽象，工具和许多组件，以使测试易于维护和易于阅读。
You have to create the tools to make testing smooth.
您必须创建工具以使测试顺利进行。
If the project has been running for a while without proper TDD, you will discover that creating appropriate tests is hard. You will face two problems: first, you will have code hard to test, and second, you will have few or no abstractions to help write rich tests. If you do not know how to start, focus on tests. Get the current feature and one similar recent feature, create a decent developer tests for each one. Not just the code of the test, but also the code of the tools for testing both; you have to create the tools to make testing smooth.
如果项目运行了一段时间而没有正确的TDD，您将发现创建适当的测试很困难。 您将面临两个问题：首先，您将具有难以测试的代码，其次，您将很少或没有抽象来帮助编写丰富的测试。 如果您不知道如何开始，请集中精力进行测试。 获得当前功能和一项类似的近期功能，为每个功能创建一个不错的开发人员测试。 不仅是测试代码，而且还有测试工具的代码； 您必须创建工具以使测试顺利进行。
行动2：将TDD和ATDD配对 (Action 2: Pair TDD and ATDD)
When we talk about TDD, we talk about how the developer creates tests that drive development, but with agile, TDD goes beyond the developer.
当我们谈论TDD时，我们谈论的是开发人员如何创建驱动开发的测试，但是在敏捷的情况下，TDD超越了开发人员。
TDD is all in one practice. When we say that we write tests before development, we do not focus only on developer tests; we also talk about tests that QA and Product do. And this is a game-changer.
TDD是一种实践。 当我们说在开发之前编写测试时，我们不仅关注开发人员测试，还关注开发人员的测试。 我们还讨论了质量检查和产品进行的测试。 这是改变游戏规则的人。
The first problem of decoupling QA from the developer is that the developer is never sure about what to expect. He can decide to implement fewer cases and leave QA to reject the code if some case is missing, or he can overwork and make sure that QA will find nothing, but spending far more resources than required.
将质量检查与开发人员脱钩的第一个问题是，开发人员永远无法确定预期的结果。 他可以决定实施更少的案例，如果缺少某些案例，可以让质量检查人员拒绝代码，或者他可以过度工作，确保质量检查人员一无所获，但是所花费的资源远远超出了要求。
The second problem is the lack of communication and common language between all roles. When Product has one idea, the developer understands another thing, and the QA has a different final interpretation. All this lack of understanding slows down all the development; roles work based on guesses instead of targets.
第二个问题是所有角色之间缺乏沟通和通用语言。 当产品有一个主意时，开发人员就会理解另一件事，并且质量保证会有不同的最终解释。 所有这些缺乏了解会减缓所有发展； 角色基于猜测而不是目标进行工作。
When QA is after Developers, it creates a black market of defects.
当质量检查人员追赶开发人员时，就会造成缺陷的黑市。
The third problem is the most severe one: it creates a black market of defects. It is reasonable to think that the developer has an incentive to finish sooner to implement a feature. And, if there is a QA team after him, a QA team that will always find something, he can relax some cases and deliver sooner the feature. It will raise defects, but he will finish sooner. Similar happens to QA; if QA finds no bugs, which value have? So they value positively finding bugs. Both incentives create a feedback loop that amplifies the number of defects found and increases the project’s cost.
第三个问题是最严重的问题：它造成了缺陷的黑市。 有理由认为，开发人员有动力早日完成功能。 而且，如果有QA团队在后面，那么QA团队总是会找到一些东西，他可以放松一些情况，并尽快提供该功能。 这会带来一些缺陷，但他会早日完成。 质量检查的情况与此类似。 如果质量检查未发现错误，哪个值有？ 因此，他们非常重视发现错误。 两种激励措施都会产生一个反馈循环，从而扩大发现的缺陷数量并增加项目成本。
All three problems have one solution: ATDD: Acceptance Test-Driven Development — BDD is one implementation of ATDD — . ATDD assumes that there is a broader TDD loop that is driven by Acceptance Tests.
所有这三个问题都有一个解决方案：ATDD：验收测试驱动开发— BDD是ATDD的一种实现。 ATDD假定存在一个由验收测试驱动的更广泛的TDD循环。
Acceptance Tests are tests written in a natural language, like English. One of the most famous variants is the Gherkin syntax (https://cucumber.io/docs/gherkin/). It is essential because those tests have two properties: first, they are executed automatically by a program; second, they are understood and discussed by every member of your organization without ambiguities. They have high value, and they are the perfect documentation for all functionalities that your product has.
验收测试是以自然语言(例如英语)编写的测试。 Gherkin语法( https://cucumber.io/docs/gherkin/ )是最著名的变体之一。 这一点很重要，因为这些测试具有两个属性：第一，它们由程序自动执行；第二，它们由程序自动执行。 其次，组织的每个成员都会理解和讨论它们，而不会产生歧义。 它们具有很高的价值，并且是您产品具有的所有功能的完美文档。
There are two levels in tests: Acceptance tests and Developer tests. Both test the same thing, but they use different languages and different degrees of integration.
测试分为两个级别：验收测试和开发人员测试。 两者都测试同一件事，但是它们使用不同的语言和不同的集成度。
With ATDD, Product can write the first version of a feature’s primary cases, developers can start to implement them, and QA can begin reviewing the cases and adding tests to avoid defects before appearing. Three roles are on the same agenda, and no defects should appear once the developer has finished the development.
使用ATDD，Product可以编写功能主要案例的第一个版本，开发人员可以开始实施它们，而QA可以开始审查案例并添加测试以避免出现缺陷。 三个角色在同一个议程上，一旦开发人员完成开发，就不应出现任何缺陷。
Write Acceptance tests before the development.
在开发之前编写验收测试。
ATDD has one more advantage: acceptance tests and developer tests are very similar. The most significant difference is the language, natural language vs. coding language, and the degree of integration. With acceptance tests, the developer knows precisely which tests write, and they probably would have excellent quality. In some projects, in some cases, the developers do not need to use developer tests in all cases, and some teams, developers also implements the automation of acceptance tests.
ATDD还有一个优势：验收测试和开发人员测试非常相似。 最显着的区别是语言，自然语言与编码语言以及集成程度。 通过验收测试，开发人员可以准确地知道编写哪些测试，并且它们可能具有出色的质量。 在某些项目中，在某些情况下，开发人员无需在所有情况下都使用开发人员测试，并且在某些团队中，开发人员还实现了验收测试的自动化。
加起来 (Summing-up)
This article focus on the main hazards and main actions that we need to implement TDD successfully. The main reason why TDD adoption fails is that we test the application manually; it can be because of a lack of expertise on TDD, but also because we were unable to create a good test base. Unit tests are one of the leading causes of TDD’s failure; focus on developer tests instead.
本文重点介绍成功实施TDD所需的主要危害和主要措施。 采用TDD失败的主要原因是我们手动测试了应用程序。 可能是因为缺乏TDD专业知识，也可能是因为我们无法建立良好的测试基础。 单元测试是TDD失败的主要原因之一。 而是专注于开发人员测试。
If you want to convert your team to TDD, focus on tests: you should have the best quality possible in the test code. But also embrace ATDD, or BDD; if you are planning to create those tests anyway, better start with them so the whole team can work more effectively.
如果要将团队转换为TDD，请专注于测试：您应该在测试代码中拥有最好的质量。 但也要拥抱ATDD或BDD； 如果您打算无论如何创建这些测试，最好从它们开始，以便整个团队可以更有效地工作。
This article does not explain why TDD is good, or how to write tests; it assumes that you are already familiar with the concepts. If you need to know more, please write a comment.
本文没有解释为什么TDD很好，或者如何编写测试； 它假定您已经熟悉这些概念。 如果您需要了解更多信息，请写评论。
翻译自: https://medium.com/@drpicox/successfully-adopting-tdd-in-your-team-f2bc333ca59a
采用tdd实现计算器
994
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
