我对 FP 的所有描述都是使用Python 测试框架做到的。但最重要的特性 -- 可能也是具体情况中最有用的特性 -- 是它消除了副作用（或者至少对一些特殊领域，例如单一体，有一些牵制作用）。
绝大部分程序错误 -- 和促使程序员求助于调试来解决的问题 -- 之所以会发生，是因为在程序执行过程期间，变量包含了意外的值。函数程序只不过根本就不为变量分配值，从而避免了这一特殊问题。
让我们看一段相当普通的命令代码。它的目的是打印出乘积大于 25 的几对数字的列表。组成各对的数字本身是从另外两个列表中挑选出的。这种操作与程序员在他们程序段中实际执行的操作差不多。实现这一目的的命令方法如下：
这个项目太小，以至于没有什么可能出错。但我们的目的可能嵌在要同时实现许多其它目的的代码中。用 "more stuff" 注释的那些部分是副作用可能导致错误发生的地方。在这些地方中的任何一处，变量 xs、ys、bigmuls、x、 y 有可能获得假设节略代码中的意外值。而且，在执行完这一段代码后，所有变量都可能具有稍后代码可能需要也可能不需要的一些值。
很明显，可以使用函数／实例形式的封装和有关作用域的考虑来防止出现这种类型的错误。而且，您总是可以在执行完变量后 del 它们。但在实际中，这些指出类型的错误非常普遍。
对于 Python 测试框架，您会发现 Zope 社区有一些有意思的现象。Zope 社区并不为解决每个问题构建大型工具，而是构建小型的功能有限的工具，这些工具能够连接在一起。目前，zope.testing 模块本身实际上根本没有提供检测测试的机制！
相反，zope.testing 让程序员自己寻找每个模块中需要运行的测试并把它们集中在一个列表中。它在每个测试模块中只寻找一个东西：test_suite() 函数，这个函数应该返回标准 unittest.TestSuite 类的实例，其中包含模块定义的测试。
使用 zope.testing 的一些程序员在 test_suite() 函数中手工地创建和维护测试列表。其他程序员通过编写定制代码发现已经定义的可用测试。但是，最有意思的方法是使用另一个 Zope 包 z3c.testsetup，它能够像其他现代 Python 测试框架一样自动地发现包中的测试。
这一现象再次说明 Zope 程序员倾向于编写小型代码块，然后使用它们构建框架，而不是编写大型的全面解决方案。z3c.testsetup 包不包含可以选择测试的命令行界面，也不包含可以显示测试结果的输出模块；它完全依靠 zope.testing 实现这些功能。
实际上，z3c.testsetup 用户一般不使用 zope.testing 的测试模块发现功能。相反，他们绕开 zope.testing 的算法，按照它的默认行为只寻找名为 test.py 的模块，然后在整个源代码树中只提供一个采用此名称的模块。在最简单的情况下，他们的 test.py 像下面这样：
【编辑推荐】
