#Chapter 1
>第一章
##A Brief Tour
>快速预览
###About This Chapter
>关于本章
There are a lot of principles, patterns, and smells in this book—and even more patterns that couldn’t fit into the book. Do you need to learn them all? Do you need to use them all? Probably not! This chapter provides an abbreviated introduction to the bulk of the material in the entire book. You can use it as a quick tour of the material before diving into particular patterns or smells of interest. You can also use it as a warm-up before exploring the more detailed narrative chapters.
>本书中有许多原则、模式、代码异味—甚至还有更多的模式不适合出现在本书中。
我想你并不需要全部的学习和使用他们。本章节为整本书的大量内容做了一个精简的介绍。
你可以在深入到特定的模式或代码异味之前，将它作为一个快速预览。你同样可以将它作为探索更详细的叙述章节之前的热身。
###The Simplest Test Automation Strategy That Could Possibly Work
>能使用的最简单的自动化测试策略
There is a simple test automation strategy that will work for many, many projects. This section describes this minimal test strategy. The principles, patterns, and smells referenced here are the core patterns that will serve us well in the long run. If we learn to apply them effectively, we will probably be successful in our test automation endeavors. If we find that we really cannot make the minimal test strategy work on our project by using these patterns, we can fall back to the alternative patterns listed in the full descriptions of these patterns and in the other narratives.
>这是一种可以在许多项目中使用的，简单的自动化测试策略。本节将描述这个最小的测试策略。
这里提及的这些原则、模式和代码异味将是长期为我们服务的核心模式。
如果我们能够学会高效的应用他们，那么我们将在自动化测试的尝试中取得成功。
如果我们发现无法使用这个最小策略将这些模式用于我们的项目，
我们还可以选择一些非传统的模式，他们将在这些模式的完整描述和其他叙述中列出。
I have laid out this simple strategy in five parts:
>我将这个简单策略分为五个部分
* Development Process: How the process we use to develop the code affects our tests.
>开发过程：用于开发影响到测试的代码的过程。
* Customer Tests: The first tests we should write as the ultimate definition of “what done looks like.”
>用户测试：我们应该写的第一个测试，用于最终定义“操作完成后应该是什么情况”
* Unit Tests: The tests that help our design emerge incrementally and
ensure that all our code is tested.
>单元测试：单元测试用于帮助我们逐渐展现出设计意图，并且保证代码是经过测试的。
* Design for Testability: The patterns that make our design easier to test,
thereby reducing the cost of test automation.
>设计代码的可测试性：用于确保代码更容易进行测试的模式，因此也可以降低自动化测试的开销。
* Test Organization: How we can organize our Test Methods (page 348)
and Testcase Classes (page 373).
>测试组织：我们应当如何组织测试方法(348页)和测试类(373页)
###Development Process
>开发过程
First things first: When do we write our tests? Writing tests before we write our software has several benefits. In particular, it gives us an agreed-upon definition of what success looks like.
>重中之重：我们什么时候编写测试？在开始编写软件之前编写测试有几个好处。
特别是他给了我们软件正确的表现的约定。
When doing new software development, we strive to do storytest-driven development by first automating a suite of customer tests that verify the functionality provided by the application. To ensure that all of our software is tested, we augment these tests with a suite of unit tests that verify all code paths or, at a minimum, all the code paths that are not covered by the customer tests. We can use code coverage tools to discover which code is not being exercised and then retrofit unit tests to accommodate the untested code.
>在开发新的软件时，我们应该争取使用一组自动化的用户测试来确保程序所提供的功能正确。
要想保证所有的软件都经过测试，我们还需要增加一组单元测试用于确保所有的代码路径，或者
至少是所有没有被用户测试覆盖的代码路径正确。我们可以使用代码覆盖检测工具来发现
哪些代码没有被测试，然后添加单元测试来包括这些未测试的代码。
By organizing the unit tests and customer tests into separate test suites, we ensure that we can run just the unit tests or just the customer tests if necessary. The unit tests should always pass before we check them in; this is what we mean by the phrase “keep the bar green.” To ensure that the unit tests are run frequently, we can include them in the Smoke Tests [SCM] that are run as part of the Integration Build [SCM]. Although many of the customer tests will fail until the corresponding functionality is built, it is nevertheless useful to run all the passing customer tests as part of the integration build phase—but only if this step does not slow the build down too much. In that case, we can leave them out of the check-in build and simply run them every night.
>我们需要把单元测试和用户测试组织到相互独立的测试组件中，来确保我们可以在有需要的情况下单独运行他们其中的一个。
在我们签入代码之前，必须保证单元测试是通过的；这就是我们平常所说的
“保持这个条是绿色的”。为了确保单元测试被频繁执行，我们可以把它包含到
Smoke Tests[SCM]作为整体构建的一部分运行。许多用户测试都将会失败，直到相关的功能被构建。
尽管如此，把通过用户测试作为成体构建的一部分还是相当有用的，只要他没有使得构建过程变慢太多。
如果测试过程太慢，我们可以将它排除在签入构建之外，仅仅只是每天晚上执行他们。
We can ensure that our software is testable by doing test-driven development (TDD). That is, we write the unit tests before we write the code, and we use the tests to help us define the software’s design. This strategy helps concentrate all the business logic that needs verification in well-defined objects that can be tested independently of the database. Although we should also have unit tests for the data access layer and the database, we try to keep the dependency on the
database to a minimum in the unit tests for the business logic.
>我们可以通过测试驱动开发(TDD)来确保我们的软件是可测试的。测试驱动开发就是在我们编写代码之前先编写单元测试，
并且通过这些测试来帮助我们定义软件的设计。这个策略帮助我们专注于那些需要被验证的业务逻辑，是否被良好定义在可以独立于数据库
进行测试的对象中。尽管我们也需要对数据访问层和数据库进行单元测试，我们还是尽量尝试保持单元测试中得业务逻辑对数据库的依赖最小化。
###Customer Tests
>用户测试
The customer tests should capture the essence of what the customer wants the system to do. Enumerating the tests before we begin their development is an important step whether or not we actually automate the tests, because it helps the development team understand what the customer really wants; these tests define what success looks like. We can automate the tests using Scripted Tests (page 285) or Data-Driven Tests (page 288) depending on who is pre- paring the tests; customers can take part in test automation if we use Data- Driven Tests. On rare occasions, we might even use Recorded Tests (page 278) for regression testing an existing application while we refactor the application to improve its testability. Of course, we usually discard these tests once we have developed other tests that cover the functionality, because Recorded Tests tend to be Fragile Tests (page 239).
>
