翻译 Secrets of the JavaScript Ninja 边译边学（8）

Secrets of the JavaScript Ninja 边译边学（8）

2.2 Test generation
2.2 生成测试用例

Robert Frost wrote that good fences make good neighbors, but in the world of web applications, indeed any programming discipline, good tests make good code.

Robert Frost写过：与邻居保持距离，能够使邻里关系处的更好，但是在web应用程序的世界里，实际上是在任何编码规则里，好的测试用例能够成就优秀的代码。

  Note the emphasis on the word good. It’s quite possible to have an extensive test suite that doesn’t really help the quality of our code one iota if the tests are poorly constructed. Good tests exhibit three important characteristics:
  注意上文中用的是词语：好的。如果测试用例构建得不好，那么很可能会出现一个对我们的代码质量没有任何帮助的测试套件。好的测试用例有如下三个重要特点：

• Repeatability – our test results should be highly reproducible. Tests run repeatedly should always produce the exact same results. If test results are nondeterministic, how would we know what are valid results versus invalid results? Additionally this helps to make sure that your tests aren’t dependent upon external factors issues like network or CPU loads.

• Simplicity – our tests should focus on testing one thing. We should strive to remove as much HTML markup, CSS, or JavaScript as we can without disrupting the intent of the test case. The more that we remove, the greater the likelihood that the test case will only be influenced by the specific code that we are trying to test.

• Independence – our tests should execute in isolation. We must strive to not make the results from one test be dependent upon another. We should break tests down into their smallest possible unit, which helps us to determine the exact source of a bug when an error occurs.

• 可复现的 – 我们的测试结果应该是高度可复现的. 重复运行测试应该总是呈现相同的结果. 如果测试结果是不确定的, 那我们如何区分哪个是有效测试结果哪个是无效的? 而且这让我们确定自己的测试用例不受外界因素（例如网络环境或者CPU占用情况）影响.

• 简洁的 – 我们的测试用例应该只关注测试这一件事. 我们应该在不影响测试目的的情况下尽量排除HTML标记、CSS或者JavaScript这类因素。我们移除的因素越多，我们的测试用例越可能只受被测试功能代码的影响。

• 独立的 – 我们的测试应该独立运行. 我们应该尽可能保证一个测试用例的结果不依赖于另一个测试用例的结果。我们应该尽量分解测试用例，直到达到其最小可能单元，这样当出现错误时，我们可以精确地定位出错代码。

  There are a number of approaches that can be used for constructing tests, with the two primary approaches being: deconstructive tests and constructive tests. Let’s examine what each of these approaches entails:
  构建测试用例有很多方法，其中两个主要方法是：构建测试用例和解构测试用例。让我们检查一下这些方法的细节：

• Deconstructive test cases
  Deconstructive test cases are created when existing code is whittled down (deconstructed) to isolate a problem, eliminating anything that’s not germane to the issue. This helps us to achieve the three characteristics listed above. We might start with a complete site, but after removing extra markup, CSS, and JavaScript, we arrive at a smaller case that reproduces the problem.

• Constructive test cases
  With a constructive test case you start from a known good, reduced case and build up until we’re able to reproduce the bug in question. In order to use this style of testing we’ll need a couple simple test files from which to build up tests, and a way to generate these new tests with a clean copy of your code.

• 解构测试用例
  解构测试用例是在对现有代码进行精简（解构）以隔离问题时创建的，从而消除与问题无关的所有内容。 这有助于我们实现上面列出的三个特点。 我们可以从一个完整的示例代码开始，这个示例删除了额外无关的标记、CSS和JavaScript，这样我们得到了一个可以再现这个问题的更精简的例子。

• 构建测试用例
  有了一个有建设性的测试用例，您就可以从一个已知良好的、简化的用例开始，逐步构建直到可以重现问题为止。 为了使用这种类型的测试，我们需要几个简单的测试文件，以便从中构建测试，以及一个使用干净的代码副本来产生这些新测试用例的方法。

  Let’s see an example of constructive testing.
  让我们来看一下构建测试代码的示例。

  When creating reduced test cases, we can start with a few HTML files with minimum functionality already included in them. We might even have different starting files for various functional areas; for example, one for DOM manipulation, one for Ajax tests, one for animations, and so on.
  当构建最小完整测试用例时，我们可以从一些包含最少功能点的HTML文件开始。为测试不同的功能范围，我们可以从不同文件开始；比如，有的测试DOM操作，有的测试Ajax，有的测试动画，等等。

  For example, Listing 2.3 shows a simple DOM test case used to test jQuery.
  例如，清单2.3所示展示了一个用来测试JQuery的简单DOM测试用例。

  To generate a test, with a clean copy of the code base, I use a little shell script to check the library, copy over the test case, and build the test suite, as shown in Listing 2.4, showing file gen.sh .
  为了使用一份干净的代码副本创建测试，我使用了一个小小的shell脚本来测试这个库，复制测试用例，然后创建一个测试单元，清单2.4展示了这个shell脚本文件gen.sh。

  The above script would be executed using the command line:
  使用如下命令行执行上面的代码：

./gen.sh mytest dom

which would pull in the DOM test case from dom.html in the git repository.
这样即可将git仓库中的dom.html测试用例下载下来。

  Another alternative, entirely, is to use a pre-built service designed for creating simple test cases. One of these services is JSBin (http://jsbin.com/), a simple tool for building a test case that then becomes available at a unique URL - you can even include copies of some of the most popular JavaScript libraries. An example of JSBin is shown in Figure 2.4.
  另一个完全不同的选择时使用已构建好的服务创建简单的测试用例。其中之一是JSBIN（http://jsbin.com/），这是一个构建测试用例的简单工具，在一个特定的URL地址中，你构建的测试用例会是可用的-你甚至可以在其中添加一些当今流行的JavaScript库副本来测试。图2.4是JSBIN的一个示例。

  With the tools and knowledge in place for figuring out how to create test cases, we can start to build test suites around these cases so that it becomes easier to run these tests over and over again. Let’s look into that.
  有了关于如何创建测试用例的工具和知识，我们可以着手围绕这些案例创建测试单元，以便更容易地多次运行这些测试用例。让我们来看看。