1. 先测试，后编码
对程序的各个部分建立测试也是非常重要的（这也称为单元测试）。测试驱动编程：Test-driven programming
1)精确的需求说明：
程序设计的理念是以编写测试程序开始，然后编写可通过测试的程序。测试程序就是你的需求说明，它帮助你在开发程序时不偏离需求
举例：编写一个模块，其中包括一个使用给定的宽和高计算长方形面积的函数。在开始编码前，首先要编写一个单元测试，其中包括带有几个答案已经清楚的例子：
1 from area import rect_area 2 3 height = 3 4 width =4 5 correct_answer = 12 6 answer = rect_area(height, width) 7 if answer == correct_answer: 8 print 'Test passed' 9 else: 10 print 'Test failed'
2)为改变而计划：
自动化测试除了在编写程序上给予巨大帮助外，还可以避免在实施修改时增加错误
代码覆盖度——coverage是测试知识中重要的部分。在运行测试的时候，有可能并没有运行代码的全部，即使在理想情况下也是这样（理想的情况应该是运行程序的所有可能状态，使用所有可能的输入，但是这不太可能）。优秀的测试程序组的目标之一是拥有良好的覆盖度，实现这个目标的方法之一是使用覆盖度工具，它可以衡量在测试过程中实际运行的代码的百分比。目前还没有可用的标准化覆盖度工具，搜索“Python测试覆盖度”会找到一个些可用的工具。其中一个是trace.py程序
3)测试的4步:
A：指出需要的新特性。可以先记录下来，然后为其编写一个测试
B：编写特性的概要代码，这样程序就可以运行而没有任何语法等方面的错误，但是测试会失败。看到测试失败是很重要的，这样就能确定测试可以失败。如果测试代码中出现 了错误，那么就有可能不管出现任何情况，测试都会成功，这样等于没测试任何东西。再强调一遍：在试图让测试成功前，先要看到它失败
C：为特性的概要编写虚设代码(dummy code)，能满足测试要求就行。不用准确地实现功能，只要保证测试可以通过即可。这样一来就可以保证在开发的时候总是通过测试了 （除了第一次运行测试的时候），甚至在最初实现功能时亦是如此
D：现在重写（或者重构，Refactor）代码，这样它就会做自己应该做的事，从而保证测试一直重构
2. 测试工具
标准库中的模块可以帮助我们自动完成测试过程：
unitest：通用测试框架
doctest：简单一些的模块，是检查文档用的，但是对于编写单元测试也很在行
1) doctest：交互式解释器的会话可以是将文档字符串（docstring）写入文档的一种有用的形式。假如，假设我编写了一个求数字的平方的函数，并且在它的文档字符串中添加了一个例子：
1 def square(x): 2 ''' 3 Squares a number and returns the result. 4 5 >>> square(2) 6 4 7 >>> square(3) 8 9 9 ''' 10 return x*x
文档字符串中也包括了一些文本。这和测试又有什么关系？假设square函数定义在my_math模块（也就是叫做my_math.py的文件）中。之后就可以在底部增加下面的代码：
1 def square(x): 2 ''' 3 Squares a number and returns the result. 4 5 >>> square(2) 6 4 7 >>> square(3) 8 9 9 ''' 10 return x*x 11 12 if __name__ == '__main__': 13 import doctest.my_math 14 doctest.testmod(my_math)
doctest.testmod函数从一个模块读取所有文档字符串，找出所有看起来像是在交互式解释器中输入的例子的文本，之后检查例子是否符合实例要求（如果想实践“先测试，后编码”的编程方式，unittest框架是更好的选择）
为了获得更多输入，可以为脚本设定-v（意为verbose，即详述）选项开关：$ python my_math.py -v
2)unittest：doctest简单易用，unittest（基于Java的流行测试框架JUnit）则更灵活和强大。
假设要写模块my_math，其中包括计算乘积的函数product。从哪开始呢？对于测试来说，当然（位于文件test_my_math.py中）是使用unittest模块中的TestCase类
1 #使用unittest框架的简单测试 2 import unittest, my_math 3 4 class ProductTestCase(unittest.TestCase): 5 6 def testIntegers(self): 7 for x in range(-10,10): 8 for y in range(-10,10): 9 p = my_math.product(x,y) 10 self.failUnless(p == x*y, 'Tnteger multiplication failed') 11 12 13 def testFloats(self): 14 for x in range(-10,10): 15 for y in range(-10,10): 16 x = x/10.0 17 y = y/10.0 18 p = my_math.product(x,y) 19 self.failUnless(p == x*y, 'Float multiplication failed') 20 21 #unittest.main函数负责运行测试，它会实例化所有TestCase的子类，运行所有名字以test开头的方法 22 if __name__ == '__main__' : unitteset.main()
如果定义了叫做startUp和tearDown的方法，它们就会在运行每个测试方法之前和之后执行，这样就可以用这些方法为所有测试提供一般的初始化和清理代码，这被称为测试夹具（test fixture）
3：单元测试以外的东西：
源代码检查和分析：源代码检查是一种寻找代码中普通错误或者问题的方法（有点像编译器处理静态语言，但远不如此）。分析则是查明程序到底跑多快的方法。之所以按照这个顺序讨论这章的主题，是因为黄金法则“使其工作、使其更好、使其更快”的缘故。单元测试可以让程序可以工作，源代码检查可以让程序更好，最后，分析会让程序更快。
1)使用PyChecker和PyLint检查源代码
2)分析：试图让代码提速前，有个非常重要的规则需要注意（以及KISS原则，Keep It Small and Simple，即让它小且简单，或者YAGNI原则，You Ain't Gonna Need It，即并不需要它）——不成熟的优化是万恶之源
拿Unix的发明人之一Ken Thompson的话说就是“拿不准的时候，就穷举”。换句话说，如果不是特别需要的话，就不要在精巧的算法或者漂亮的优化技巧上有过多的担心。如果程序已经够快了，那么干净、简单并且易懂的代码的价值比稍微快一点的程序要高得多。
如果必须进行优化的话，那么绝对应该再做其他事情之前对其进行分析（profile）。这是因为很难估计到瓶颈在哪里，除非你的程序非常简单。标准库中已经包含了一个叫做profile的分析模块（还有个更快的嵌入式C语言版本，叫hotshot）。使用分析程序非常简单，是要使用字符串参数调用它的run方法就行了
>>> import profile
>>> from my_math import product
>>> profile.run('product(1,2)')
这样做会打印出信息，其中包括各个函数和方法调用的次数，以及每个函数所花费的时间。如果提供了文件名，比如'my_math.profile'作为第二个参数来运行，那么结果就会保存到文件中。可在之后使用pastats模块检查分析结果：
>>> import pstats
>>> p = pstats.Stats('my_math.profile')
标准库中还包含一个名为timeit的模块，它是测试python小代码段运行时间的简单方法
