python基础教程总结14——测试

1. 先测试，后编码

　　对程序的各个部分建立测试也是非常重要的（这也称为单元测试）。测试驱动编程：Test-driven programming

1)精确的需求说明：

　　程序设计的理念是以编写测试程序开始，然后编写可通过测试的程序。测试程序就是你的需求说明，它帮助你在开发程序时不偏离需求
举例：编写一个模块，其中包括一个使用给定的宽和高计算长方形面积的函数。在开始编码前，首先要编写一个单元测试，其中包括带有几个答案已经清楚的例子：

from area import rect_area

height = 3
width =4
correct_answer = 12
answer = rect_area(height, width)
if answer == correct_answer:
    print 'Test passed'
else:
    print 'Test failed'

 

2)为改变而计划：

　　自动化测试除了在编写程序上给予巨大帮助外，还可以避免在实施修改时增加错误

　　代码覆盖度——coverage是测试知识中重要的部分。在运行测试的时候，有可能并没有运行代码的全部，即使在理想情况下也是这样（理想的情况应该是运行程序的所有可能状态，使用所有可能的输入，但是这不太可能）。优秀的测试程序组的目标之一是拥有良好的覆盖度，实现这个目标的方法之一是使用覆盖度工具，它可以衡量在测试过程中实际运行的代码的百分比。目前还没有可用的标准化覆盖度工具，搜索“Python测试覆盖度”会找到一个些可用的工具。其中一个是trace.py程序

 

3)测试的4步:

　　A：指出需要的新特性。可以先记录下来，然后为其编写一个测试
　　B：编写特性的概要代码，这样程序就可以运行而没有任何语法等方面的错误，但是测试会失败。看到测试失败是很重要的，这样就能确定测试可以失败。如果测试代码中出现　　　　了错误，那么就有可能不管出现任何情况，测试都会成功，这样等于没测试任何东西。再强调一遍：在试图让测试成功前，先要看到它失败
　　C：为特性的概要编写虚设代码(dummy code)，能满足测试要求就行。不用准确地实现功能，只要保证测试可以通过即可。这样一来就可以保证在开发的时候总是通过测试了　　　　（除了第一次运行测试的时候），甚至在最初实现功能时亦是如此
　　D：现在重写（或者重构，Refactor）代码，这样它就会做自己应该做的事，从而保证测试一直重构
　　

2. 测试工具

  标准库中的模块可以帮助我们自动完成测试过程：
　　   unitest：通用测试框架
　　   doctest：简单一些的模块，是检查文档用的，但是对于编写单元测试也很在行

1) doctest：交互式解释器的会话可以是将文档字符串（docstring）写入文档的一种有用的形式。假如，假设我编写了一个求数字的平方的函数，并且在它的文档字符串中添加了一个例子：

def square(x):
    '''
    Squares a number and returns the result.

    >>> square(2)
    4
    >>> square(3)
    9
    '''
    return x*x

文档字符串中也包括了一些文本。这和测试又有什么关系？假设square函数定义在my_math模块（也就是叫做my_math.py的文件）中。之后就可以在底部增加下面的代码：

def square(x):
    '''
    Squares a number and returns the result.

    >>> square(2)
    4
    >>> square(3)
    9
    '''
    return x*x

if __name__ == '__main__':
    import doctest.my_math
    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类

 

#使用unittest框架的简单测试
import unittest, my_math

class ProductTestCase(unittest.TestCase):

    def testIntegers(self):
        for x in range(-10,10):
            for y in range(-10,10):
                p = my_math.product(x,y)
                self.failUnless(p == x*y, 'Tnteger multiplication failed')


    def testFloats(self):
        for x in range(-10,10):
            for y in range(-10,10):
                x = x/10.0
                y = y/10.0
                p = my_math.product(x,y)
            self.failUnless(p == x*y, 'Float multiplication failed')

#unittest.main函数负责运行测试，它会实例化所有TestCase的子类，运行所有名字以test开头的方法
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小代码段运行时间的简单方法