2006-03-26 校对记要
Contents
校对文件: roman.xml
章节： 第15章
本章目录
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 是你还没有编写的一个 独立测试测试用例。
JasonXie 同意
Example 15.1. The bug
- Example 15.1. The bug
例 15.1.
关于一个 Bug
JasonXie 一个不需要翻译出来吧！
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 异常。
JasonXie 同意
下一段
- After reproducing the bug, and before fixing it, you should write a test case that fails, thus illustrating the bug.
在
再现 重现这个 Bug 和 去除修改它之前你应该编写一个 失败独立测试会失败的测试用例来 描述这个 Bug说明它。
JasonXie 同意
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，<!> 现在你知道了它既然你已经知道它了，测试它就很 简单容易了。
JasonXie 同意
下一段
- Since your code has a bug, and you now have a test case that tests this bug, the test case will fail:
因为你的代码
存在有一个 Bug，并且你编写了测试这个 Bug 的 独立测试测试用例，所以 独立测试测试用例将会失败：
JasonXie 意思一样，‘存在’ 好像好听一些
Example 15.3.
- Output of romantest61.py against roman61.py
- 以 用romantest61.py 测试 roman61.py 的 输出 结果
JasonXie 同意
Example 15.4. Fixing the bug (roman62.py)
- This file is available in py/roman/stage6/ in the examples directory.
这个文件可以
从 在例子目录下的 py/roman/stage6/ 的 examples 目录中 获得 找到 。
JasonXie 同意
Example 15.4. 说明1
- Only two lines of code are required: an explicit check for an empty string, and a raise statement.
只需要两行代码：
直白的一行直接检查空字符串和一 条行 raise 语句。
JasonXie 同意
Example 15.5.
- Output of romantest62.py against roman62.py
- 以 用romantest62.py 测试 roman62.py 的 输出 结果
JasonXie 同意
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 修正没有影响到其他部分。 停止编程不需要再编程了。
JasonXie 同意
最后一段
- 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）。 
独立测试 
测试用例
JasonXie 同意