2006-03-26 校对记要
校对文件: roman.xml
本章目录
Chapter 15. Refactoring 重构
15.1. Handling bugs
bugs 处理 处理bug 15.2. Handling changing requirements 应对
要求需求变化 15.3. Refactoring
重组 重构 - 15.4. Postscript 后记
- 15.5. Summary 小结
第15章第1节
第一段
- Despite your best efforts to write comprehensive unit tests, bugs happen. What do I mean by “bug”? A bug is a test case you haven't written yet.
尽管你很努力
的地编写全面的单元测试，但是 bug 还是会出现。 我所说的 “bug” 是什么呢？ Bug 是你还没有编写的一个 独立测试测试用例。
Example 15.1. The bug
- Example 15.1. The bug
例 15.1.
关于一个 Bug
Example 15.1.说明1
Remember in the previous section when you kept seeing that an empty string would match the regular expression you were using to check for valid Roman numerals? Well, it turns out that this is still true for the final version of the regular expression. And that's a bug; you want an empty string to raise an InvalidRomanNumeralError exception just like any other sequence of characters that don't represent a valid Roman numeral.
- 在前面的 章节中 你 看到你有注意到一个空字符串会匹配 用以那个检查罗马数字有效性的正则表达式认为空字符串有效了吗？ 对于最终版本中的正则表达式这一点仍然没有改变。这就是一个 Bug ，你希望对于空字符串能够像对待其他无效的罗马数字表示一样引发 InvalidRomanNumeralError 异常。
下一段
- After reproducing the bug, and before fixing it, you should write a test case that fails, thus illustrating the bug.
在
再现 重现这个 Bug 和 去除修改它之前你应该编写一个 失败独立测试会失败的测试用例来 描述这个 Bug说明它。
Example 15.2.说明1
Pretty simple stuff here. Call fromRoman with an empty string and make sure it raises an InvalidRomanNumeralError exception. The hard part was finding the bug; now that you know about it, testing for it is the easy part.
这里很简单。以空字符串调用 fromRoman 并确保
它会引发一个 InvalidRomanNumeralError 异常。 难点在于找出 Bug，<!> 现在你知道了它既然你已经知道它了，测试它就很 简单容易了。
下一段
- Since your code has a bug, and you now have a test case that tests this bug, the test case will fail:
因为你的代码
存在有一个 Bug，并且你编写了测试这个 Bug 的 独立测试测试用例，所以 独立测试测试用例将会失败：
Example 15.3.
- Output of romantest61.py against roman61.py
- 以 用romantest61.py 测试 roman61.py 的 输出 结果
Example 15.4. Fixing the bug (roman62.py)
- This file is available in py/roman/stage6/ in the examples directory.
这个程序可以
从 在例子目录下的 py/roman/stage6/ 的 examples 目录中 获得 找到 。
Example 15.4. 说明1
- Only two lines of code are required: an explicit check for an empty string, and a raise statement.
只需要两行代码：
直白的一行直接检查空字符串和一 条行 raise 语句。
Example 15.5.
- Output of romantest62.py against roman62.py
- 以 用romantest62.py 测试 roman62.py 的 输出 结果
Example 15.5. 的说明
- The blank string test case now passes, so the bug is fixed.
空字符串
独立测试测试用例现在通过了，说明 Bug 被改正了。 - All the other test cases still pass, which means that this bug fix didn't break anything else. Stop coding.
所有其他
独立测试测试用例依然通过，证明这个 Bug 修正没有影响到其他部分。 停止编程不需要再编程了。
最后一段
- Coding this way does not make fixing bugs any easier. Simple bugs (like this one) require simple test cases; complex bugs will require complex test cases. In a testing-centric environment, it may seem like it takes longer to fix a bug, since you need to articulate in code exactly what the bug is (to write the test case), then fix the bug itself. Then if the test case doesn't pass right away, you need to figure out whether the fix was wrong, or whether the test case itself has a bug in it. However, in the long run, this back-and-forth between test code and code tested pays for itself, because it makes it more likely that bugs are fixed correctly the first time. Also, since you can easily re-run all the test cases along with your new one, you are much less likely to break old code when fixing new code. Today's unit test is tomorrow's regression test.
- 这样编程，并没有令 Bug 修正变得简单。 简单的 Bug （就像这一个）需要简单的独立测试，复杂 Bug 则需要复杂的独立测试。 在测试为核心的氛围下，这 看起来 似乎延长了修正 Bug 的时间，因为你需要先贴切地描述出 Bug （编写独立测试）然后才去修正它。 如果独立测试没能正确通过，你需要思量这个修改错了还是独立测试本身出现了 Bug。无论如何，从长远上讲，这样在测试代码和代码之间的反复是值得的，因为通常 Bug 在第一次就被修正过来了。 当然，由于任何新的更改后你都可以轻易的重新运行 所有 独立测试，新代码对老代码产生负面影响的机会也变得微乎其微。 今天的单元测试就是明天的衰退测试（regression test）。
独立测试 
测试用例