在Django/Python中编写单元测试

除了在Uni课程中快速介绍之外,我之前没有使用过单元测试.我现在正在编写一个应用程序,并希望在此过程中自学TDD.问题是,我不知道测试什么或者真的如何.

我正在编写一个Django应用程序,到目前为止只创建了模型(并自定义了管理应用程序).这就是我到目前为止编写测试的骨架的方法:

class ModelTests(TestCase):
    fixtures = ['initial_data.json',]

    def setUp(self):
        pass

    def testSSA(self):
        ssa = SSA.objects.create(name="sdfsdf", cost_center=1111, street_num=8,
                street_name="dfsdfsf Street", suburb="sdfsdfsdf",
                post_code=3333)


    def testResident(self):
        pass

    def testSSA_Client(self):
        pass

我打算编写一个函数来测试ModelTests类中的每个模型.这是编写测试的好方法吗？另外,我到底应该测试什么？创建一个完成所有领域的模型？那个半完整的模型失败了吗？测试任何特殊情况(如null和is_required = False)？我相信ORM,据我所知,它已经过严格测试,所以我不应该测试所有的方法吗？

对于用Django/Python编写的Web应用程序,我需要测试什么？一些例子会很好.

1> S.Lott..：

---

是一个在ModelTests类中测试每个模型的函数是编写测试的好方法吗？

没有.

我到底应该测试什么？

创建一个完成所有领域的模型？

那个半完整的模型失败了吗？

测试任何特殊情况(如null和is_required = False)？

我相信ORM,据我所知,它已经过严格测试,所以我不应该测试所有的方法吗？

不是那么多.

您可以测试验证规则,但在定义某些Form对象之前,这没有意义.然后你需要测试一下 - 表单是否强制执行所有规则.每个表单至少需要一个TestCase类.函数将是一种场景 - 允许或不允许的不同输入组合.

对于每个Model类,您至少需要一个TestCase类定义.TestCases很便宜,定义了很多.

您的模型体现了您的"业务实体"定义.您的模型将具有实现业务规则的方法.你的方法会做诸如汇总,过滤,计算,聚合,减少等各种事情.您将拥有模型类的每个功能的功能.

你没有测试Django.您正在测试您的业务规则在Django中的实际工作方式.

之后,当您的应用程序中有更多内容(表单,视图,URL等)时,您将需要使用Django unittest客户端为每个URL执行每种方法.再次,每个一个TestCase

---

一旦我把骨架写出来,并为一个模型定义了两个测试,我就意识到我在浪费时间.没有什么可以测试我不确定.我还没有定义自定义方法.非常好的答案我很感激.

---

@Josh Smeaton:不要浪费时间.从长远来看,那些简单的骨架测试很有帮助.在将来,你会做一些看似微不足道的重构,其中一个蹩脚的测试会破坏,表明你错过了一些东西."当然"并不总是足够好.你需要"证明".

2> 小智..：

---

我不完全确定你要在这里测试的具体细节,我需要更多的代码片段,但我可以给你一些一般的建议.

首先,阅读"潜入Python"的单元测试章节(它是免费的在线!http://diveintopython3.ep.io/unit-testing.html),这是一般的单元测试的一个很好的解释,你需要做什么,为什么.

第二,关于TDD,这是一种有价值的做法,但要小心增长过于依赖它,因为我发现它可能导致过度指定软件,并进一步使用无法重新开发和调整的软件新任务.这只是我的经历,记住.此外,如果您不以书面形式使用它,TDD很有价值.

第三,让我感到震惊的是,针对您的具体情况的最佳建议是努力测试您的逻辑,而不是您依赖的框架逻辑.这意味着经常测试半完整模型失败等等可能不合适,因为这不是你的逻辑,而是django,所以应该已经进行了测试.更有价值的是测试一些预期的情况,您期望的实例化,您期望的异常等,以确保您的模型规范是合理的,然后转向应用程序的更实质的逻辑.