Odoo----调试与自动化测试

标题生成服务器日志来帮助调试方法

服务器崩溃时使用日志可以帮助查看运行时的情况，下面介绍如何为现有方法添加日志。例如下面的代码中加入了日志语句，存储产品的库存等级到一个文件中

from os.path import join
# 1. 代码开头从 Python 标准库引用 logging 模块
import logging
 
from odoo import models, api, exceptions
 
EXPORTS_DIR = '/srv/exports'
# 2.在定义模型类之前，为模块获取 logger
_logger = logging.getLogger(__name__)
 
class ProductProduct(models.Model):
    _inherit = 'product.product'
    @api.model
    def export_stock_level(self, stock_location):
        # 3.
        _logger.info('export stock level for %s',
                     stock_location.name)
        products = self.with_context(
            location = stock_location.id
        ).search([])
        products = products.filtered('qty_available')
        # 3.
        _logger.debug('%d products in the location',
                      len(products))
        fname = join(EXPORTS_DIR, 'stock_level.txt')
        try:
            with open(fname, 'w') as fobj:
                for prod in products:
                    fobj.write('%s\t%f\n' % (prod.name,
                                             prod.qty_available))
        except IOError:
            # 3.
            _logger.exception(
                'Error while writing to %s in %s',
                'stock_level.txt', EXPORTS_DIR)
            raise exceptions.UserError('unable to save file')

小知识

__name__变量在模块引用时由 Python 解释器自动设置，名称为模块的全称。由 Odoo 自身的引用机制，插件模块 Python 会视为 odoo.addons 的包。所以假若代码在my_module/models/book.py文件中，__name__则为odoo.addons.my_module.models.book。这样有两个好处：

• Odoo logger(记录器)的全局日志配置会应用到我们的记录器上，这源自 logging 模块的等级结构
• 日志会带有完事模型路径作为前缀，这样有且于查找产生某一日志行的来源

上述的3中使用记录器来产生日志信息，按日志等级升序有 debug, info, warning, error 和 critical 这几种方法。所有这些方法都接受%替代符以及插入消息中的其它变量。%不必自己替换，日志模块足够智能，只在日志生成时替换。如果以 INFO 日志级别运行，DEBUG 日志就会避免进行这种长期看会消耗 CPU 的替换。

这里另一个有用的方法_logger.exception()，可用于异常处理器，消息以 ERROR 级别记录，栈的轨迹也会在应用日志中打印。

扩展知识

可以在命令行或配置文件中控制日志级别，主要有两种方式

• 全局控制日志级别，命令行中使用–log-level
• 为指定记录器设置日志级别，可使用–log-handler=prefix:level。这里的 prefix 为记录器名的一段路径，日志级别为DEBUG，INFO，WARNING，ERROR或CRITICAL。如果省略prefix，则为所有日志记录器设置默认级别。例：

python odoo.py --log-handler=odoo.addons.my_module:DEBUG

• 在命令行中可多次指定–log-handler
• 也可以在 Odoo 实例的配置文件中设置日志处理器，这时使用逗号隔的 prefix:level 对。例：

log_handler = :ERROR,werkzeug:CRITICAL,odoo.service.server:INFO

标题使用 Odoo Shell 来交互式地调用方法

Odoo的 Web 端主要面向终端用户，虽然可以通过调试模式进行开发调试，但这通常并不方便，于是有了命令行界面 Odoo Shell。接下来我们就通过命令行来调用上面的export_stock_level方法，

首先执行：

# 1.进入 Odoo Shell
./odoo-bin shell -c odoo.conf --log-level=error
# 以上操作会初始化一些全局变量
# a.env为通过命令行或配置文件指定的数据库连接环境；
# b.odoo是一个导入的 odoo 包，可以获取获取该包中的所有 python 模块
# c.openerp 是为向了向下兼容所保留的 odoo 的别名
# d.self 是一个 res.users 记录集，它包含一条与 env 连接的 Odoo 超级用户记录
 
# 2.获取product.product记录集
product = env['product.product']
# 3.获取主仓库位置记录
location_stock = env.ref('stock.stock_location_stock')
# 以上两步使用 env 获取一条空记录集并通过 XML ID 查找记录
 
# 4.调用export_stock_level方法
product.export_stock_level(location_stock)
 
# 5.退出前结束事务
env.cr.commit()
# 以上步骤在这里并非必须，但如果要对数据进行修改并保存则需要执行此步。在进行 RPC 调用时 Odoo 会处理事务，但是在 shell 模式中需要自行调用 env.cr.commit()执行或 env.cr.rollback()回滚

有时应用日志不足以帮助我们定位问题，于是我们还可以使用 Python 调试器(debugger)。我们依然使用以上的export_stock_level方法进行调试，仅需进行如下修改

@api.model
def export_stock_level(self, stock_location):
    # 此处使用 set_trace()方法来打断点
    import pdb; pdb.set_trace()
...

首先使用如前所述同样的操作：

./odoo-bin shell -c odoo.conf --log-level=error
product = env['product.product']
location_stock = env.ref('stock.stock_location_stock')
product.export_stock_level(location_stock)

此时进入如下Pdb 的命令窗口界面

1、输入 a 查看当前传入方法中的参数值

2、输入 list 查看代码执行到哪一行（箭头所指处）

3、输入 next 或 n 执行到下一行，类似于 PyCharm 中的单步调试

4、输入 p 变量名查看指定变量的当前值，如(p products 或 p fname)

5、输入!fname = ‘/tmp/stock_level.txt’来修改fname对应的变量值

6、输入return 或 r来执行到当前方法结束处

7、输入cont 或 c 恢复程序执行

使用 Python 调试器手动单步调试，有以下小贴士：

• 把日志级别降低避免输出泛滥，通常建议使用 ERROR 级别。对有些日志记录如需内容更为全面，可以在命令行中使用–log-handler选项
• 添加–workers=0来避免多进程所引发的断点多次调用
• 添加–max-cron-threads=0来取消 ir.cron 定时任务的执行，以避免单步调试时触发任务产生不需要的日志和其它副面作用。

pdb 命令很多都可以通过其首字母来执行，总结如下：

• h(elp)：显示 pdb 命令的帮助
• a(rgs)：显示当前函数/方法的参数值
• l(ist)：以11行的源代码块显示，并且当前执行命令行居中显示，连续调用会在源代码中不断前进。并且可以起始和结束两个数字来指令显示区域
• p：打印变量
• pp：以美化的方式打印变量（对于列表和字母非常有用）
• u§：移到调用栈中的上一级
• d(own)：移到调用栈中的下一级
• n(ext)：执行当前行代码
• s(tep)：进入调用方法内部执行
• r(eturn)：恢复当前方法的执行直到返回行
• c(ont(inue))：恢复程序执行到下一断点
• b(reak) ：创建新的断点并显示标识符，args 可以是如下的一种：
  • 不跟参数：显示所有断点
  • 行号：在当前文件指定行打断点
  • 文件名:行号：在指定文件（在 sys.path 路径中搜索）指定行打断点
  • 函数名：在指定函数/方法的第一行打断点
• tbreak ：与 break 相似，但是在执行完断点后将取消断点，所以在循环调用中不会重复触发
• disable bp_ip：根据指定的 ID 取消断点
• enable bl_id：根据指定的 ID 激活已取消断点
• j(ump) lineno：执行指定行号的代码，通常用于重新执行代码或跳过一些行
• (!) statement：执行 Python 语句，在不与 pdb 保留字冲突时可省略!，比如因为 a 是一条pdb命令，在定义一个名为 a 的变量时需在前面加上!

扩展知识

本例中我们使用 pdb.set_trace()方法来打断点，但有时我们无法在代码中进行修改，此时可以通过在 Odoo shell 中使用 pdb.runcall()来实现。比如实现同样的调试也可以这样：

这里我们使用了 Python 标准库 pdb，同时还有 ipdb 和 pudb 都可以作为 pdb 的替代，它们命令大同小异。当前我们也完全可以借助 IDE 来进行断点调试。

使用 Python 单位测试来测试模块

Odoo 支持多种测试插件模块的书写方式，如 YAML 测试和 Python 测试。不建议给新模块写 YAML 测试，因为在未来的更新中很有可能就被删除掉了，所以这里我们只讨论 Python 单元测试。

我们依然采用本系统文章中的 my_module 来进行演示，

1、创建一个 tests 模块

mkdir my_module/tests

2、创建___init__.py 文件

from . import test_library

3、创建 test_library.py
注：user_demo 用户在安装时勾选Load demostration data 时会自动添加，否则需要在debug 模式下点击 Settings > Technical > Sequences & Identifiers > External Identifiers进行添加，也可使用其它用户

from odoo.tests.common import TransactionCase
 
class LibraryTestCase(TransactionCase):
 
    def setUp(self):
        # 使用 setUp 方法创建一本书
        super(LibraryTestCase, self).setUp()
        demo_user = self.env.ref('base.user_demo')
        demo_user.groups_id |= self.env.ref('my_module.group_librarian')
        # sudo()用于改变 self.book_model 的环境用户，这可以保证不会使用跳过各种规则的管理用户
        book_model = self.env['library.book'].sudo(demo_user)
        self.book = book_model.create(
            {
     'name': 'Test book', 'state': 'draft'}
        )
 
    def test_change_draft_available(self):
        # 将状态由 draft 修改为 available
        self.book.change_state('available')
        self.assertEqual(self.book.state, 'available')
 
    def test_change_available_draft_no_effect(self):
        # 测试一个非法状态修改：由 available 改为 draft
        self.book.change_state('available')
        self.book.change_state('draft')
        self.assertEqual(
            self.book.state,
            'draft',
            'the state cannot change from %s to draft' % self.book.state
        )

注：test_change_available_draft_no_effect方法原书应为错误代码，修改如上

按照惯例测试模块名以 test_开头，以上 TrasactionCase 继承自 Python 标准库 unittest.TestCase，通过重载 setUp和 tearDown()方法来使用：

• setUp()方法初始化用于常规操作的 self.env 属性
• teardown()方法用于数据库事务回滚，以方便测试隔离

小贴士：如在测试代码中重新定义的以上两个方法后一定要记得调用 super()实现

测试通过 test 前缀的方法定义，方法运行前后会分别调用 setUp()和 tearDown()，在方法中则可以使用 unittest.TestCase 中的任意 assertion 方法：

Method	Checks that
assertEqual(a, b)	a == b
assertNotEqual(a, b)	a != b
assertTrue(x)	bool(x) is True
assertFalse(x)	bool(x) is False
assertIn(a, b)	a in b
assertNotIn(a, b)	a not in b
assertRaises(exc, fun, *args, **kwargs)	fun(*args, **kwargs) raises exc

以上除 assertRaises 以外的方法都支持一个可选参数 msg，用于在 assertion为假时作为错误消息展示。assertRaises最好是用作上下文管理器，比如我们要测试修改记录抛出 UserError 异常，可以这么写

class TestCase(TransactionCase):
    # setUp method defines self.record
    def testWriteRaisesUserError(self):
        with self.assertRaises(UserError):
            self.record.write({
     'some_field': some_value})

如果传递给 assertRaises 的异常由代码块生成测试成功，否则失败。更多单元测试内容，参见官方标准库文档。

扩展知识

odoo.tests.common 模块中定义一些测试基类

• TransactionCase：每个测试方法单独运行，并在其后对数据库事务回滚。这表示一个测试方法所做的修改在另一个测试方法中不可见。可以使用传统的 setUp()和 tearDown()方法来进行初始化和清理
• SingleTransactionCase：所以的测试方法在同一个事务中运行，在最一个方法执行后回滚。如需对测试事例进行初始化和清理，需要继承 setUpClass()和 tearDownClass()方法。同时应记得添加@classmethod 类装饰器，否则在调用 super()时会出现一些奇怪的报错
• SavePointCase：它继承自 SingleTransactionCase 并在测试方法运行前创建一个数据库 SAVEPOINT，然后在运行完成后还原。好处在于可以独立运行测试而无需在测试间使用消耗系统的 setUp()方法重建所有数据，初始化通过 setUpClass()方法，然后每次测试后事务会还原到保存的状态

该模块还定义了两个装饰器 at_install(bool)和 post_install(bool)，默认测试在插件模块初始化后和下一个插件模块运行之前运行，对应装饰器@at_install(True)和@post_install(False)。有时需要做出调整。比和 module_a 和 module_b 继承自相同模型，但彼此没有依赖，它们都需要添加必填字段（如field_a 和 field_b）的默认值到模型。在测试时创建新记录，如果在测试时两个模型都运行，则会出错，分别运行又正常运行。原因在于比如先加载module_a，在创建新记录时 field_b 的默认值未被计算，数据库对 field_b的 NOT NULL 约束会不让记录创建。解决方案是为两个模块测试方法中添加@at_install(False)和@post_install(True)，这会强制测试在两个模块初始化完成后运行。

运行服务器测试

# 为模块添加 demo 数据
./odoo-bin -c odoo.conf --without-demo=False --stop-after-init -i my_module
./odoo-bin -c odoo.conf --test-enable --log-level=error --stop-after-init -u my_module

–test-enable 选项通知 Odoo 运行测试，–stop-after-init 标记在测试运行后停止实例，-u 更新指定模块。如果测试没有执行，则应检查模块测试数据有没有被激活，不确定的话可以执行：

UPDATE ir_module_module SET demo=true WHERE name='my_module';

也可以使用–log-level=error --log-handler=odoo.modules.loading:INFO运行测试，这样操作日志不会被输出，仅仅显示错误消息。

小贴士：Odoo 返回的状态为测试错误的次数，所以只有不是0，就表明测试失败，服务器日志中可以获取更多信息。

扩展知识

这种测试的方式最大的缺点是即使我们知道大部分代码都正常，但还是要测试整个模块，而且还要去更新整个模块。有一种简洁些的方式是可指定测试的内容（如 test_library.py）

./odoo-bin -c odoo.conf --log-level=error --stop-after-init --test-file myaddons/my_module/tests/test_library.py

这样公会运行指定文件中所定义的测试，它不会更新模块，所以如果修改了字段或数据文件而没更新的话就不会生效。

小贴士：如果测试没有报错一定要保持怀疑的态度，这有可能是你自身的错误导致的，比如忘记在 tests/init.py 中导入测试文件，通常我们会在第一次运行时通过在第一行添加 assert False 强制错误以确定是否正常运行。

使用 OCA 维护的质量工具

OCA(Odoo Community Association)在 Github 上维护有大量 Odoo 项目，该机构通过 Travis CI来进行持续集成，本节展示如何使用 OCA维护者的 QA 工具。

1、访问https://travis-ci.org/并点击 Sign in with Github 进行登录(需进行授权)

2、点击右上角姓名处进入个人资料页，然后点击 Sync Account按钮将公开代码同步到 Travis 上

3、对需要使用 Travis on 的仓库点击滑块进行激活

4、在本地仓库添加.travis.yml 文件，填入如下内容

language: python
sudo: false
cache:
  apt: true
  directories:
    - $HOME/.cache/pip
python:
  - "3.5"
addons:
  apt:
    packages:
      - expect-dev  # provides unbuffer utility
      - python-lxml  # because pip installation is slow
      - python-simplejson
      - python-serial
      - python-yaml
virtualenv:
  system_site_packages: true
env:
  global:
  - VERSION="11.0" TESTS="0" LINT_CHECK="0"
  matrix:
  - LINT_CHECK="1"
  - TESTS="1" ODOO_REPO="odoo/odoo"
  - TESTS="1" ODOO_REPO="OCA/OCB"
install:
  - git clone --depth=1 https://github.com/OCA/maintainer-quality-tools.git ${
     HOME}/maintainer-quality-tools
  - export PATH=${
     HOME}/maintainer-quality-tools/travis:${
     PATH}
  - travis_install_nightly
script:
  - travis_run_tests
after_success:
  - travis_after_tests_success

5、push 到 GitHub 上，此时再到 travis-ci.org 页面上点击项目名，此时就会开始首次 build，如果代码符合 OCA 代码标准，就会显示为绿色，Alan 使用课程代码测试时日志中显示virtualenv 执行报错，因而这里先列出一个反例

当我们在仓库上使用 Travis CI时，Trvis 会在 GitHub 上注册一个钩子(hook)，默认钩子会在每次向仓库分支 push 或 pull 请求时触发 Travis CI重建。这里使用的 Travis CI配置文件比较高阶，与https://github.com/OCA/maintainer-quality-tools中 sample_files 子目录中文件极其相近（此处移除了用于模块翻译的 transifex 配置），配置释意如下：

• addons：与 Odoo 的插件模块无关，它用于请求 Travis 在测试环境中安装一些 Ubuntu 包文件，这样我就无需从源码中安装 Python 相关包
• env：此处定义了环境变量和编译矩阵。维护者质量工具通过环境变量了解到需测试项，并且会对 env 逐行测试运行
  • VERSION：需测试的 Odoo 版本
  • LINT_CHECK：0表示不使用 flake8或 Pylint 测试，1则反之。在矩阵中，首次编译会进行 lint 检查，因为这样一旦不符合编码标准或 linter 发现错误都可以快速反馈
  • TESTS：0作用于无需测试模块，1则反之
  • ODOO_REPO：在 TESTS为1时测试 GitHub 仓库中的 Odoo，示例中使用了官方仓库以及社区补丁（OCB）进行编译， 如果不设置，仅使用官方仓库
• install：用于下载编译环境中的 maintainer-quality-tools 并调用 travis_install_nightly 工具，以在 Travis 上配置 Odoo
• script：从maintainer-quality-tools中调用 travis_run_test，这个脚本用于检测编译矩阵的环境变量并执行相应动作
• after_success：在script 部分成功运行后，travis_after_test_success 脚本会运行。在示例上下文中，脚本会用 https://coveralls.io检测模块的测试覆盖并在编译时生成报告
  可能你对于这整个复杂的配置不感兴趣，而希望使用更为轻量级的工具，那么其中的 Pylint 和 Flake8都可以独立作为静态代码检测器来使用。

使用 Pylint 检测代码

Pylint 是一个 Python的静态代码检测器，还有一个针对Odoo 的项目叫作 pylint-odoo，安装方法为：

pip install --upgrade --pre pylint-odoo
# 安装完成后可以通过指定模块路径来进行检测
pylint --load-plugins=pylint_odoo -e epylint myaddons/my_module/

此时会给出一长串建议如

Missing ./README.rst file. Template here: https://github.com/OCA/maintainer-tools/blob/master/template/module/README.rst (missing-readme)

README文件地址为https://github.com/OCA/pylint-odoo/blob/master/README.rst，比如我们不需要 missing author的提示，在该文件中找对应的代码为 C8101，就可以执行时使用-d 或–disable 来不予以检查 （也可以在配置文件中进行该设置）

pylint --load-plugins=pylint_odoo -e epylint -d C8101 myaddons/my_module/

使用 Flake8检测代码

Flake8也是一个用于检测代码格式的常用工具，支持 Python 的文本编辑器或 IDE 通过都会提供运行 flake8的的方式，在不符合编辑规范时高亮提示，使用 pip 安装

pip install flake8

在项目根目录下创建.flake8文件，这里使用 OCA 的配置文件版本

# E123,E133,E226,E241,E242 are ignored by default by pep8 and flake8
# F811 is legal in odoo 8 when we implement 2 interfaces for a method
# F999 pylint support this case with expected tests
ignore = E123,E133,E226,E241,E242,F811,F601
max-line-length = 79
exclude = __unported__,__init__.py

此时使用 flake8加文件或目录路径执行即可，更建议的做法是在编辑器中进行设置

flake8 myaddons/my_module/