Development in its pure form is not only writing code, but also a number of manipulations that are necessary for its correct and timely work. Testing in development takes the lion's share of both time and resources, but proper testing will bring only time savings and the best result for the client.
纯粹的开发方式不仅是编写代码，而且是正确，及时地工作所必需的许多操作。 开发中的测试占据了时间和资源的绝大部分，但是正确的测试只会节省时间并为客户带来最佳结果。
手动还是自动测试？ (Manual or Automatic Testing?)
The software is invariably created by people, tested by people and, in most cases, used by people. The worst dream of any responsible tester is to miss a serious bug. The tester tries carefully examines the requirements and writes test cases, carefully checks the product, and after the release, the user reports a critical problem within a week.
该软件总是由人创建，经过人测试并且在大多数情况下是由人使用的。 任何负责任的测试人员最糟糕的梦想是错过一个严重的错误。 测试人员尝试仔细检查需求并编写测试用例，仔细检查产品，并在发布后，用户在一周内报告严重问题。
How many bugs that are obvious to others are missing?
遗失了多少对其他人显而易见的错误？
And, maybe, it's time to work only with automatic testers? Automatic testers or QA
而且，也许是时候只使用自动测试仪了？ 自动测试仪或质量检查
Automated tests catch errors earlier, preventing them from ever being deployed. They offer a faster feedback loop for programmers because they do not need to go through each path in their application manually. A well-written test can take milliseconds, and with a good development setup, you don’t even have to leave your editor. If you compare this with the manual approach a hundred times a day, you can save a good chunk of time. This allows developers to more quickly implement functions since they can confidently write code without opening a browser.
自动化测试可以更早地发现错误，从而无法部署它们。 它们为程序员提供了更快的反馈循环，因为他们不需要手动遍历应用程序中的每个路径。 编写良好的测试可能要花费毫秒，而且有了良好的开发设置，您甚至不必离开编辑器。 如果您每天将这种方法与手动方法进行比较一百次，则可以节省大量时间。 这使开发人员可以更快地实现功能，因为他们可以放心地编写代码而无需打开浏览器。
When applications grow without a reliable test suite, frequent errors silently penetrate their code. And as the application grows, the overall solution is to scale the number of hands on the deck — hiring specialized testers (QA), which will never be as effective as automated tests in trapping regressions. QA increases the time it takes to implement features because developers must communicate with each other with another person. Compared to a set of tests, it's expensive.
当应用程序在没有可靠的测试套件的情况下增长时，频繁的错误会静默地渗透到其代码中。 并且随着应用程序的增长，整体解决方案是扩展平台上的人员数量-雇用专业测试人员(QA)，这在捕获回归方面永远不会像自动测试那样有效。 质量保证(QA)增加了实现功能所需的时间，因为开发人员必须与其他人进行交流。 与一组测试相比，它很昂贵。
This does not mean that QA is absolutely useless, but they should be hired in addition to a good test suite, and not as a replacement. Although hand-held testers are not as effective as computers when searching for regressions, they are much better at testing the subjective qualities of software, such as user interfaces.
这并不意味着QA绝对没有用，但除了良好的测试套件外，还应聘用他们，而不是替代他们。 尽管手持式测试仪在搜索回归时不如计算机有效，但它们在测试软件的主观质量(如用户界面)方面要好得多。
测试类型 (Types of Tests)
Let's look at the different types of tests. At one end is unit tests. These tests isolate individual components, proving that they provide the expected behavior regardless of the surrounding system. Because of this, unit tests are usually small and fast.
让我们看一下不同类型的测试。 一方面是单元测试。 这些测试隔离了各个组件，证明了它们可以提供预期的行为，而与周围的系统无关。 因此，单元测试通常很小而又快速。
In the real world, these components do not exist in a vacuum: they must interact with each other. One component can expect a collaborator to have a specific interface if, in fact, he has a completely different one. Despite the fact that all tests pass, the software as a whole is broken.
在现实世界中，这些组件并不是真空存在的：它们必须彼此交互。 实际上，如果一个协作者拥有完全不同的界面，则他可以期望它具有特定的界面。 尽管所有测试都通过了，但软件整体还是坏掉的。
Here are the integration tests. These tests use the system as a whole, rather than its individual components. They usually do this by simulating a user trying to complete a task in software. Instead of accessing call methods or collaborators calls, integration tests relate to clicking and typing as a user.
这是集成测试。 这些测试使用整个系统，而不是单个组件。 他们通常通过模拟试图在软件中完成任务的用户来执行此操作。 集成测试不是访问调用方法或协作者调用，而是与用户单击和键入有关。
The best way to create your own test set, using a combination of tests. This is a suite that contains several high-level integration tests that cover the overall functionality of the application, several middle-level tests that cover the subsystem in more detail, and many unit tests to cover the details of each component.
使用测试组合来创建自己的测试集的最佳方法。 这是一个套件，包含几个涵盖应用程序整体功能的高级集成测试，几个涵盖子系统的更详细的中级测试以及涵盖每个组件详细信息的许多单元测试。
This approach corresponds to the strength of each type of test when trying to minimize their disadvantages, for example, a slow execution time.
当试图最大程度地减少缺点(例如执行时间缓慢)时，此方法对应于每种测试的强度。
Development process stages
开发过程阶段
测试驱动的开发过程 (Test Driven Development Process)
Automated tests are probably the best way to gain confidence in a growing code base. To increase this confidence and achieve big gains in time saving and clean code, it is recommended to write code using a process called Test Driven Development. TDD is a process that uses tests to develop designs and applications. It starts with the Red, Green, Refactor development cycle.
自动化测试可能是增强对不断增长的代码库的信心的最佳方法。 为了增加这种信心并在节省时间和清理代码方面获得更大的收益，建议使用称为“测试驱动开发”的过程来编写代码。 TDD是使用测试来开发设计和应用程序的过程。 它从红色，绿色，重构开发周期开始。
Red, Green, Refactor is a series of steps that lead to the development of this function or the correction of an error.
红色，绿色，重构是导致开发此功能或纠正错误的一系列步骤。
When solving problems with TDD, you need to decide where to start testing the code. Starting from a high level, checking how the user interacts with the system, and then turn to zero? Or start with a low-level development and move towards the final function? The answer will vary from person to person and function to function.
解决TDD问题时，您需要确定从哪里开始测试代码。 从高层次开始，检查用户如何与系统交互，然后变为零？ 还是从低级开发开始，然后过渡到最终功能？ 答案因人而异，因职能而异。
If a test is originally written, it does not mean that test development is used. When performing a Red, Green, Refactor cycle, it is important to write code only in response to error messages that result from testing failures. This ensures that functions that are not tested will not be implemented.
如果测试是最初编写的，则并不意味着将使用测试开发。 在执行红色，绿色，重构循环时，仅响应测试失败所导致的错误消息编写代码非常重要。 这样可确保不会执行未经测试的功能。
行为驱动的开发过程 (Behavior Driven Development Process)
The software development methodology Behavior Driven Development is an offshoot from Test Driven Development.
软件开发方法“行为驱动开发”是“测试驱动开发”的分支。
The main idea of this methodology is to combine in the process of developing purely technical interests and business interests, thereby allowing management staff and programmers to speak the same language. For communication between these sides, natural language constructs understandable to a non-expert is used, such as admin panels, registration forms that usually express the behavior of a software product and the expected results.
这种方法的主要思想是在发展纯技术利益和商业利益的过程中结合起来，从而允许管理人员和程序员说同一种语言。 对于这些方面之间的通信，使用了非专家可以理解的自然语言构造，例如管理面板，通常表示软件产品行为和预期结果的注册表格。
The BDD methodology is an extension of TDD in the sense that before writing any test, you must first describe the desired result of the added functionality in a subject-oriented language. After this is done, the constructions of this language are translated by experts or special software into the test description.
BDD方法是TDD的扩展，因为在编写任何测试之前，您必须首先以面向主题的语言描述所添加功能的期望结果。 完成此操作后，专家或特殊软件会将这种语言的结构转换为测试说明。
域驱动设计 (Domain Driven Design)
BDD can also be described as the intersection between Domain-Driven Design (DDD) and TDD. Domain-Driven design is an approach to software development aiming to deal with projects with complex business rules where collaboration between developers and domain experts (typically, this role is assumed by the client) is necessary to set a common language and a domain model that can be translated into very specific and detailed requirements. In BDD, these specific requirements are used to drive the development process in the first step of its cycle. From business to tech testing process
BDD也可以描述为域驱动设计(DDD)与TDD之间的交集。 域驱动设计是一种软件开发方法，旨在处理具有复杂业务规则的项目，开发人员和域专家之间的协作(通常由客户承担此角色)对于设置通用语言和域模型是必需的。转化为非常具体和详细的要求。 在BDD中，这些特定要求用于在其周期的第一步中驱动开发过程。 从业务到技术测试流程
最佳用于测试的是什么？ (What is best used for testing?)
Testing is first and foremost a good tone rule. Mostly created their own set of tools and applications and didn’t give up on manual testing at all, which in our opinion is considered optimal in the work of each IT company.
测试首先是一个好的音调规则。 大多数情况下，他们创建了自己的工具和应用程序集，完全没有放弃手工测试，我们认为这对于每个IT公司的工作都是最佳的。
Let's review the tools we have chosen for testing.
让我们回顾一下我们选择用于测试的工具。
1. RSpec (1. RSpec)
To verify Ruby code, use a tool written in Ruby RSpec. This is a behavior-based development environment (BDD) and writing sufficient code (TDD). The entire work of the Amoniac team aimed at the clarity of development and the satisfaction of the end customer. That is why We selected RSpec because we consider it the best and most effective tool in our testing work.
要验证Ruby代码，请使用用Ruby RSpec编写的工具。 这是一个基于行为的开发环境(BDD)，并且编写了足够的代码(TDD)。 Amoniac团队的整个工作旨在使开发过程清晰易懂，并使最终客户满意。 这就是我们之所以选择RSpec的原因，因为我们认为RSpec是我们测试工作中最好，最有效的工具。
2.萝卜 (2. Turnip)
Turnip is an open source Ruby gem that provides a platform for acceptance tests and aims to solve some of the issues faced when writing specifications with Cucumber. Cucumber supports various programming languages and is also very popular as an acceptance testing framework.
Turnip是一个开放源码的Ruby gem，它提供了一个用于接受测试的平台，旨在解决用Cucumber编写规范时面临的一些问题。 Cucumber支持各种编程语言，并且作为验收测试框架也非常受欢迎。
Turnip works like Cucumber as it is a framework that primarily supports acceptance testing. Although Turnip is not as feature-rich as Cucumber, it is simple and powerful, which makes acceptance testing easier and more accessible.
芜菁的工作方式类似于Cucumber，因为它是主要支持验收测试的框架。 尽管Turnip不像Cucumber那样功能丰富，但它简单而强大，这使验收测试更加容易且更易于访问。
3.工厂机器人 (3. Factory Bot)
Factory Bot is a helper for writing factories for Ruby tests. It was previously known as Factory Girl. For older versions, use FactoryGirl instead of FactoryBot.
Factory Bot是编写用于Ruby测试的工厂的助手。 它以前被称为Factory Girl。 对于较旧的版本，请使用FactoryGirl而不是FactoryBot。
This library is used to conveniently create instances of models, something on which we will test. For example, some Users, and Articles, and Projects, and with Task. We cannot create objects every time by filling in all required fields. This is where the Factory Bot will come in handy. It is enough to define a pattern once and then generate new entities based on it.
该库用于方便地创建模型实例，我们将在这些实例上进行测试。 例如，某些用户，文章，项目以及任务。 我们不能每次都填写所有必填字段来创建对象。 这是Factory Bot派上用场的地方。 只需定义一次模式，然后基于该模式生成新实体就足够了。
4.录像机 (4. VCR)
Approach for preventing external requests is to record a live interaction and ‘replay’ it back during tests. The VCR gem has a concept of cassettes which will record your test suites outgoing HTTP requests and then replay them for future test runs.
防止外部请求的方法是记录实时互动并在测试过程中“回放”。 VCR gem有一个盒式磁带的概念，它将记录您的测试套件传出的HTTP请求，然后重播它们以供将来进行测试。
Considerations when using VCR:
使用VCR时的注意事项：
- Communication on how cassettes are shared with other developers. 与其他开发人员共享盒带通信方式。
- Needs the external service to be available for a first test run. 需要外部服务可用于首次测试运行。
- Difficult to simulate errors. 难以模拟错误。
The VCR gem is really useful if you have methods that need to make an API request. You don’t want to make API requests during tests, especially if the API has some kind of rate limit. What you could do is create a text file mocking the response you get from the web service you’re making the API to and do the tests that way, or you can use the VCR gem.
如果您有需要发出API请求的方法，则VCR gem非常有用。 您不想在测试期间发出API请求，尤其是在API具有某种速率限制的情况下。 您可以做的是创建一个文本文件，模拟从您正在制作API的Web服务获得的响应并以这种方式进行测试，或者可以使用VCR gem。
5. WebMock (5. WebMock)
WebMock is a library for stubbing HTTP requests and setting expectations on HTTP requests in Ruby. With WebMock, developers can match requests based on method, URI, headers, and body, and match the same headers in different representations.
WebMock是一个用于在Ruby中存根HTTP请求并设置HTTP请求期望的库。 使用WebMock，开发人员可以根据方法，URI，标头和正文匹配请求，并以不同的表示形式匹配相同的标头。
摘要 (Summary)
And in the end, we can easily say that yes, testing is a huge lion's share of the time saved as by the developer and as the end client. It is this work that allows you to make exactly the product you see in a head in the end, and this is a guarantee to a client that it works flawlessly.
最后，我们可以轻松地说，是的，测试是开发人员和最终客户节省的时间的绝大部分。 正是这项工作使您可以精确地制造出最终在头脑中看到的产品，并且向客户保证了它可以完美工作。
Set of tools are capable of testing in seconds and in this case, writing a test will be a time saving and not vice versa. Writing a test gives error messages, the test that will tell you what to do next. And, perhaps, it looks like a kind of robotization, but with a growing number of projects and their scale, it becomes just a necessity.
这套工具能够在几秒钟内进行测试，在这种情况下，编写测试将节省时间，反之亦然。 编写测试会给出错误消息，该测试将告诉您下一步该做什么。 而且，也许它看起来像是一种机械化，但是随着项目和规模的不断增长，这已成为一种必需。
But should never forget that on the way of testing there can be a significant number of traps and anti-patterns that should be avoided, because a poorly written test can have the opposite effect and lead to a crash.
但是永远不要忘记，在测试的过程中应该避免大量陷阱和反模式，因为编写不当的测试会产生相反的效果并导致崩溃。
The test gives you confidence that you can move on. Both software and QA could and should be used together to tame existing projects and solve larger and more complex ones!
测试使您充满信心，可以继续前进。 软件和质量保证可以并且应该一起使用以驯服现有项目并解决更大，更复杂的项目！
1547
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
