Differences between revisions 1 and 4 (spanning 3 versions)
Revision 1 as of 2006-03-22 17:17:42
Size: 8137
Editor: wolfg
Comment:
Revision 4 as of 2006-03-22 17:23:36
Size: 8339
Editor: wolfg
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
 * '''''来自于极限编程,强调测试是第一位的,以测试为优先,就像test-driven development,所以是不是该译成 “以测试优先为原则的编程”或“以测试第一为原则的编程”。本想这样译:“测试第一的编程”,但感觉好像有歧义,待讨论。'''''  * '''''来自于极限编程的概念,强调测试是第一位的,以测试为优先,就像test-driven development,所以是不是该译成 “以测试优先为原则的编程”或“以测试第一为原则的编程”。本想这样译:“测试第一的编程”,但感觉好像有歧义,待讨论。'''''
Line 65: Line 65:
 * doc string 是Python特有的注释,这里作者想强调unittest会把unittest的方法的doc string打印出来,所以我把the method翻译出来。string倒是没必要翻译。
Line 66: Line 67:
'''3rd item''' '''3rd item in 2nd note list'''
Line 71: Line 72:
'''4th item''' '''4th item in 2nd note list'''
Line 74: Line 75:
 * '''''总而言之,由于至少一个测试用例没有通过,单元测试失败了。一个测试用例没能通过时,unittest会区分是由于失败(failures)还是错误(errors)。 失败是指调用assertXYZ 方法(比如assertEqual 或者 assertRaises)时,断言的情况没有发生或预期的异常没有被引发。而错误是指你测试的代码或单元测试本身发生了某种异常。例如:testFromRomanCase 方法 (“fromRoman 只接受大写输入”)就是一个错误,因为调用 numeral.upper() 引发了一个 AttributeError 异常,因toRoman的返回值不是期望的字符串类型。但是, testZero (“toRoman 应该在输入 0 时失败”)是一个失败,因为调用 fromRoman 没有引发一个 assertRaises 期待的异常: InvalidRomanNumeral。'''''







   
   


 * '''''总而言之,由于至少一个测试用例没有通过,单元测试失败了。一个测试用例没能通过时,unittest会区分是由于失败(failures)还是错误(errors)。 失败是指调用assertXYZ 方法(比如assertEqual 或者 assertRaises)时,断言的情况没有发生或预期的异常没有被引发。而错误是指你测试的代码或单元测试本身发生了某种异常。例如:testFromRomanCase 方法 (“fromRoman 只接受大写输入”)就是一个错误,因为调用 numeral.upper() 引发了一个 AttributeError 异常,因toRoman的返回值不是期望的字符串类型。但是, testZero (“toRoman 应该在输入 0 时失败”)是一个失败,因为调用 fromRoman 没有引发一个 assertRaises 期待的异常: InvalidRomanNumeral。''''

2006-03-22 校对记要

TableOfContents

校对文件: roman.xml

章节: [http://www.woodpecker.org.cn/obp/diveintopython-zh-5.4/zh-cn/dist/htmlflat/diveintopython.html#roman1.5 第14章]

说明粗体是修改的位置,斜体是原文及翻译,斜粗体是校对后的修改

已确定,所有的test case都翻译成“测试用例”

The title

  • Test-First Programming

  • 程序第一测试

  • 来自于极限编程的概念,强调测试是第一位的,以测试为优先,就像test-driven development,所以是不是该译成 “以测试优先为原则的编程”或“以测试第一为原则的编程”。本想这样译:“测试第一的编程”,但感觉好像有歧义,待讨论。

第14章第1节 roman.py, 第 1 阶段

[http://www.woodpecker.org.cn/obp/diveintopython-zh-5.4/zh-cn/dist/htmlflat/diveintopython.html#roman.stage1]

1st paragraph:

  • Now that the unit tests are complete, it's time to start writing the code that the test cases are attempting to test. You're going to do this in stages, so you can see all the unit tests fail, then watch them pass one by one as you fill in the gaps in roman.py.

  • 到目前为止,单元测试已经完成,到了开始编写被单元测试测试的代码的时候了。你将一步步完成这个工作,你将看到所有的单元测试都是失败的,然后一个个攻破也同时填充了 roman.py。

  • 到目前为止,单元测试已经完成,是时候开始编写被单元测试测试的代码了。 你将分阶段地完成这个工作,因此开始时所有的单元测试都是失败的,但当你逐步完成roman.py的同时你会看到它们一个个地通过(测试)。

Example code location

  • This file is available in py/roman/stage1/ in the examples directory.

  • 这个程序可以从 py/roman/stage1/ 的 examples 目录中获得。

  • 这个程序可以在例子目录下的py/roman/stage1/目录中找到。

  • (说明:我下载了源码包,py/roman/stage1/是其中的一个目录。)

2nd sentence of 1st item in note list

  • Exceptions are classes, and you create your own by subclassing existing exceptions.

  • 你可以通过建立已有异常的子类来构建。

  • 异常也是类,通过继承已有的异常,你可以创建自定义的异常。

  • 这里,Exception似乎不翻译更好。

3rd sentence of 1st item in note list

  • It is strongly recommended (but not required) that you subclass Exception, which is the base class that all built-in exceptions inherit from.

  • 强烈建议(但不是必须)你从建立 Exception 这个所有内建异常的父类的子类入手。

  • 强烈建议(但不是必须)你继承Exception来定义自己的异常,因为它是所有内建异常的基类。

5th sentence of 1st item in note list

  • This is a matter of style

  • 这是一个风格问题

  • 这是个人习惯的问题

Last item in note list

  • At this stage, you want to define the API of each of your functions, but you don't want to code them yet, so you stub them out using the Python reserved word pass.

  • 在这一步中你需要定义每个函数的 API ,但是你不需要立刻编写他们,而是以 Python 关键字 pass 一笔带过。

  • 在这一步中你只是想定义每个函数的 API,而不想具体实现它们,因此你以 Python 的关键字 pass 一笔带过。

1st paragraph after note list

  • Now for the big moment (drum roll please): you're finally going to run the unit test against this stubby little module. At this point, every test case should fail. In fact, if any test case passes in stage 1, you should go back to romantest.py and re-evaluate why you coded a test so useless that it passes with do-nothing functions.

  • 重要的时刻到了(请打起鼓来):你终于要对这个简陋的小模块开始运行单元测试了。 目前而言,每一个独立测试都应该失败。 事实上,任何独立测试在第 1 步通过,你都因该返回 romantest.py 重新评价一下,为什么你的测试代码如此没用,什么都不作的函数都能通过测试。

  • 重要的时刻到了(请打起鼓来):你终于要对这个简陋的小模块开始运行单元测试了。 目前而言,每一个测试用例都应该失败。 事实上,如果任意一个测试用例在此时通过,你都应该回头看看 romantest.py,仔细想想为什么你写的测试代码如此没用,以至于连什么都不做的函数都能通过测试。

2nd sentence of 1st item in 2nd note list

  • For each test case, it prints out the doc string of the method and whether that test passed or failed.

  • 对于每个独立测试,无论测试通过与否,都会输出 doc string。

  • 对于每个测试用例,无论测试通过与否,都会输出这个方法的doc字符串。

  • doc string 是Python特有的注释,这里作者想强调unittest会把unittest的方法的doc string打印出来,所以我把the method翻译出来。string倒是没必要翻译。

3rd item in 2nd note list

  • After the detail, unittest displays a summary of how many tests were performed and how long it took.

  • 在这些细节后面, unittest 给出了一个关于测试运行的总结和运行耗时。

  • 在这些细节后面, unittest 给出了一个关于被执行测试的个数和花费时间的总结。

4th item in 2nd note list

  • Overall, the unit test failed because at least one test case did not pass. When a test case doesn't pass, unittest distinguishes between failures and errors. A failure is a call to an assertXYZ method, like assertEqual or assertRaises, that fails because the asserted condition is not true or the expected exception was not raised. An error is any other sort of exception raised in the code you're testing or the unit test case itself. For instance, the testFromRomanCase method (“fromRoman should only accept uppercase input”) was an error, because the call to numeral.upper() raised an AttributeError exception, because toRoman was supposed to return a string but didn't. But testZero (“toRoman should fail with 0 input”) was a failure, because the call to fromRoman did not raise the InvalidRomanNumeral exception that assertRaises was looking for.

  • 总而言之,任何一个独立测试不能通过都会导致单元测试失败。 当一个独立测试没能通过, unittest 能在失败和错误间进行分辨。 失败则调用 assertXYZ 方法, 比如: assertEqual 或者 assertRaises,证明这个失败可能是由于例外情况的产生或者预期异常没有引发而导致。 一个错误不是任何类型的异常溢出或者单元测试本身的问题。例如:testFromRomanCase 方法 (“fromRoman 只接受大写输入”)就是一个错误,因为调用 numeral.upper() 引发了一个 AttributeError 异常,因为没有返回 toRoman 支持的字符串类型的返回值。 但是, testZero (“toRoman 应该在输入 0 时失败”)是一个失败,因为调用 fromRoman 没有引发一个 assertRaises 期待的异常: InvalidRomanNumeral

  • 总而言之,由于至少一个测试用例没有通过,单元测试失败了。一个测试用例没能通过时,unittest会区分是由于失败(failures)还是错误(errors)。 失败是指调用assertXYZ 方法(比如assertEqual 或者 assertRaises)时,断言的情况没有发生或预期的异常没有被引发。而错误是指你测试的代码或单元测试本身发生了某种异常。例如:testFromRomanCase 方法 (“fromRoman 只接受大写输入”)就是一个错误,因为调用 numeral.upper() 引发了一个 AttributeError 异常,因toRoman的返回值不是期望的字符串类型。但是, testZero (“toRoman 应该在输入 0 时失败”)是一个失败,因为调用 fromRoman 没有引发一个 assertRaises 期待的异常: InvalidRomanNumeral'

DiveIntoPythonZh/2006-03-22 (last edited 2009-12-25 07:13:55 by localhost)