django-smoketest

动机

Django的烟雾测试框架。

烟雾测试是在生产环境中运行的测试，用于快速检测主要系统性问题。例如，在运行部署之后，您希望快速检查一切是否运行正常，以便在出现问题的情况下可以快速回滚。这种情况通常意味着访问网站并手动点击几个链接（最多如此）。

您可能已经拥有验证代码低层部分的正确性的单元测试，以及运行在预发布服务器或CI系统上的集成和验收测试。也许您甚至拥有自动配置管理，以确保您的预发布服务器配置与生产环境的精确副本。因此，从逻辑上讲，如果您的代码在预发布服务器上通过所有测试，并且生产服务器的配置相同，那么在生产环境中一切必须运行正常。对吧？如果世界如此简单那就太好了。当然我们知道事实并非如此。这就是为什么我们希望烟雾测试实际上可以验证系统的主要组件是否基本功能正常，能够相互通信，我们没有做类似编写依赖于尚未在生产环境中设置为正确值的新环境变量的愚蠢事情。

您可能不希望在生效的生产设置中运行单元测试或集成测试。谁知道会发生什么疯狂的后果？测试数据可能喷洒在整个生产数据库中，从文件系统中删除用户数据，太阳从西边升起，从东边落下？

这就是烟幕测试的作用。烟幕测试应该在生产环境中运行时是安全的。验证应用程序是否可以连接到数据库，预期的文件系统挂载是否就位等。填补现有测试覆盖范围和生产环境之间的最后差距。但所有这些都要小心绕过生产数据。

我还发现自己经常编写小的视图来支持临时监控。例如，如果一个应用程序依赖于NFS挂载进行一些不频繁的操作，而这个挂载有变得过时的倾向，那么一个每隔几分钟（或通过nagios或其他监控应用程序）运行一次的cron作业，并让应用程序尝试从挂载读取文件，可以帮助我们确保在用户遇到它之前就发出警告。

入门指南

安装 django-smoketest

$ pip install django-smoketest

将 smoketest 添加到您的 INSTALLED_APPS。

在您想为烟幕测试定义的每个应用程序中，创建一个 smoke.py 文件或一个 smoke 目录，其中包含一个 __init__.py 和一个或多个包含测试的python文件。

在您的 urls.py 中，添加如下内容：

('smoketest/', include('smoketest.urls'))

到您的 urlpatterns。

在您的 smoke.py（或模块）中，您可以放置如下内容：

from smoketest import SmokeTest
from myapp.models import FooModel


class DemoTest(SmokeTest):
    def test_foomodel_reads(self):
        """ just make sure we can read data from the db """
        cnt = FooModel.objects.all().count()
        self.assertTrue(cnt > 0)

    def test_foomodel_writes(self):
        """ make sure we can also write to the database
        but do not leave any test detritus around. Smoketests
		are automatically rolled back.
        """
        f = FooModel.objects.create()

现在，如果您向 http://yourapp/smoketest/ 发起 GET 请求，django-smoketest 将遍历您的代码，找到任何 smoke 模块，并运行您定义的测试（如果您使用过unittest或nose，您应该知道这个意思）

PASS
test classes: 1
tests run: 3
tests passed: 3
tests failed: 0
tests errored: 0
time: 1200.307861328ms

因此，如果您从监控脚本或作为自动化部署的一部分调用它，您只需检查结果是否为 PASS。

如果测试失败或出错，您将得到类似以下的内容：

FAIL
test classes: 1
tests run: 8
tests passed: 5
tests failed: 2
tests errored: 1
time: 3300.07861328ms
module1.smoke.DemoTest.test_foo failed
module1.smoke.DemoTest.test_bar failed
module1.smoke.DemoTest.test_baz errored

如果您的HTTP客户端在 Accept: 标头中使用 application/json，则响应将是包含相同信息的JSON对象，但以更容易解析的形式

$ curl -H "Accept: application/json" http://yourapp/smoketest/
{"status": "FAIL", "tests_failed": 2,
 "errored_tests": ["module1.smoke.DemoTest.test_baz"],
 "tests_run": 8, "test_classes": 1, "tests_passed": 5,
 "failed_tests": ["module1.smoke.DemoTest.test_foo",
 "module1.smoke.DemoTest.test_foo"], "tests_errored": 1,
 "time": 1.6458759307861328}

问题：我正在考虑使输出简单以自动解析，但我们或许应该继续使用unittest的现有输出格式？

API

主要类是 smoketests.SmokeTest，它应该被视为与 unittest.TestCase 等效。它将做基本上在那里做同样的事情，运行 setUp 和 tearDown 方法，并支持通常的 assertEquals、assertRaises、assertTrue 方法。

所有烟幕测试都包装在一个数据库事务中，然后在该事务运行后回滚。这让您可以做可能具有破坏性的事情，而让数据库为您清理。关于确保您使用支持事务的数据库以及它只能回滚数据库操作而不是其他副作用等常规警告仍然适用。

默认情况下，django-smoketest将遍历您的 INSTALLED_APPS 中提到的所有应用程序，查找烟幕测试。如果您定义了一个包含应用程序列表的 SMOKETEST_SKIP_APPS 设置，django-smoketest将绕过其中提到的任何应用程序。

支持的断言（到目前为止）

• assertEqual(a, b)
• assertNotEqual(a, b)
• assertTrue(t)
• assertFalse(x)
• assertIs(a, b)
• assertIsNot(a, b)
• assertIsNone(x)
• assertIsNotNone(x)
• assertIn(a, b)
• assertNotIn(a, b)
• assertIsInstance(a, b)
• assertNotIsInstance(a, b)
• assertRaises(exception, function)
• assertLess(a, b)
• assertLessEqual(a, b)
• assertGreater(a, b)
• assertGreaterEqual(a, b)
• assertAlmostEqual(a, b)
• assertNotAlmostEqual(a, b)

所有调用都接受自定义消息作为最后一个参数（msg），就像unittest库中的所有assert调用一样。

开放问题

我们应支持哪些unittest/nose标志、约定等？例如：--failfast？输出详尽程度？在特定情况下能够选择或跳过特定的测试？自动超时（许多烟雾测试涉及尝试连接到外部服务，如果超过指定时间则失败）？

进度

待办事项

• 我认为它只处理smoke.py文件或smoke/__init__.py，而且暂时还不会在子模块（如smoke/foo.py）中找到子类。
• setUpClass/tearDownClass
• 扩展的assert*方法（在smoketest/__init__.py中列出）

已完成

• 遍历INSTALLED_APPLICATIONS并查找/运行烟雾测试
• 以简单文本格式报告数字
• 运行setUp和tearDown方法
• 当测试失败/出错时，报告哪些失败了/出错了
• 在测试失败/错误报告中提供正确的module.class.method信息
• 支持unittest的基本预期assert*方法集合
• JSON输出
• 记录测试运行时间并在输出中包含
• 在回滚事务中运行测试
• 在错误报告中提供附加信息（异常/堆栈跟踪）（Kristijan Mitrovic）
• 在断言中支持消息（Kristijan Mitrovic）
• SMOKETEST_SKIP_APPS