锐客网

  1. 首页 > 生活百科 > it技术 > >

python函数实验报告的简单介绍( 六 )

IT技术模块


在编写测试模块之前，我们需要思考都需要哪些测试 。我们需要测试3种不同的数据类型：列表、集合与字典 。对于列表，需要测试的是插入项、删除项或修改项的值 。对于集合，我们必须测试向其中添加或删除一个项 。对于字典，我们必须测试的是插入一个项、修改一个项的值、删除一个项 。此外，还必须要测试的是在失败的情况下，不会有任何改变实际生效 。
结构上看，测试不同数据类型实质上是一样的，因此，我们将只为测试列表编写测试用例，而将其他的留作练习 。test_Atomic.py模块必须导入unittest模块与要进行测试的Atomic模块 。
创建unittest文件时，我们通常创建的是模块而非程序 。在每个模块内部，我们定义一个或多个unittest.TestCase子类 。比如，test_Atomic.py模块中仅一个单独的 unittest-TestCase子类，也就是TestAtomic (稍后将对其进行讲解)，并以如下两行结束:
if name == "__main__":
unittest.main()
这两行使得该模块可以单独运行 。当然，该模块也可以被导入并从其他测试程序中运行——如果这只是多个测试套件中的一个 ， 这一点是有意义的 。
如果想要从其他测试程序中运行test_Atomic.py模块，那么可以编写一个与此类似的程序 。我们习惯于使用unittest模块执行doctests,比如：
import unittest
import test_Atomic
suite = unittest.TestLoader().loadTestsFromTestCase(test_Atomic.TestAtomic)
runner = unittest.TextTestRunner()
pnnt(runner.run(suite))
这里，我们已经创建了一个单独的套件，这是通过让unittest模块读取test_Atomic 模块实现的 ， 并且使用其每一个test*()方法(本实例中是test_list_success()、test_list_fail()，稍后很快就会看到)作为测试用例 。
我们现在将查看TestAtomic类的实现 。对通常的子类(不包括unittest.TestCase 子类)，不怎么常见的是，没有必要实现初始化程序 。在这一案例中 ， 我们将需要建立 一个方法，但不需要清理方法，并且我们将实现两个测试用例 。
def setUp(self)：
self.original_list = list(range(10))
我们已经使用了 unittest.TestCase.setUp()方法来创建单独的测试数据片段 。
def test_list_succeed(self):
items = self.original_list[:]
with Atomic.Atomic(items) as atomic:
atomic.append(1999)
atomic.insert(2, -915)
del atomic[5]
atomic[4]= -782
atomic.insert(0, -9)
self.assertEqual(items,
[-9, 0, 1, -915, 2, -782, 5, 6, 7, 8, 9, 1999])
def test_list_fail(self):
items = self.original_list[:]
with self.assertRaises(AttributeError):
with Atomic.Atomic(items) as atomic:
atomic.append(1999)
atomic.insert(2, -915)
del atomic[5]
atomic[4] = -782
atomic.poop() # Typo
self.assertListEqual(items, self.original_list)
这里，我们直接在测试方法中编写了测试代码，而不需要一个内部函数，也不再使用unittest.TestCase.assertRaised()作为上下文管理器(期望代码产生AttributeError) 。最后我们也使用了 Python 3.1 的 unittest.TestCase.assertListEqual()方法 。
正如我们已经看到的，Python的测试模块易于使用，并且极为有用 ， 在我们使用 TDD的情况下更是如此 。它们还有比这里展示的要多得多的大量功能与特征——比如，跳过测试的能力，这有助于理解平台差别——并且这些都有很好的文档支持 。缺失的一个功能——但nose与py.test提供了——是测试发现 ， 尽管这一特征被期望在后续的Python版本(或许与Python 3.2—起)中出现 。
性能剖析（Profiling）
如果程序运行很慢 ， 或者消耗了比预期内要多得多的内存，那么问题通常是选择的算法或数据结构不合适，或者是以低效的方式进行实现 。不管问题的原因是什么，最好的方法都是准确地找到问题发生的地方,而不只是检査代码并试图对其进行优化 。随机优化会导致引入bug,或者对程序中本来对程序整体性能并没有实际影响的部分进行提速，而这并非解释器耗费大部分时间的地方 。

推荐阅读


上一篇：oracle拼接表，oracle语句拼接

下一篇：视频号电脑直播审核多久，视频号直播要求