Question

我对编写测试有些新意。我发现自己一直在努力保持我的setUp干净简洁，而不是试图用uber-setUp完成太多。

我的问题是，你如何分开测试？

您的测试是否包含一行或两行独立步骤代码？

def test_public_items():
    item1 = PublicItem()
    item2 = PublicItem()
    assertEqual(public_items, [item1, item2])

或者你是否将其纳入setUp无论如何？

如果是这样的话，你如何处理测试类分离？当一组测试需要不同的setUp而另一组测试时，你是否创建了一个新类？

Answer 1

我相信你在这里遇到了几个anti-patterns

设置过多
不恰当地分享灯具。

经验法则是特定测试夹具中的所有测试都需要Setup（）方法中的代码。

如果你编写的test（）需要或多或少的设置，那么它可能是一个暗示它属于一个新的测试夹具。惯性创建一个新的测试夹具..是将设置代码滚雪成一个大泥球 - 试图为所有测试做所有事情。很可能会损害可读性......您无法在设置代码中看到测试，其中大部分甚至可能与您正在查看的测试无关。

那说可以在测试中通过常规设置测试一些特定的设置说明。（这属于Arrange-Act-Assert三元组中的第一个）。但是，如果您在多个测试中重复这些指令 - 您应该将所有这些测试带到一个新的测试夹具，其中

setup_of_new_fixture = old_setup + recurring_arrange_instruction

Answer 2

是的，一个文本夹具（体现在一个类中）应该是一组测试，分享设置和拆卸的常见需求。

理想情况下，单元测试应命名为testThisConditionHolds。 public_items不是“条件”。无论那个令人难以置信的黑魔法public_items应该来自哪里，我都会编写如下测试：

def testNoPublicItemsRecordedIfNoneDefined(self):
    assertEqual([], public_items)

def testOnePublicItemsIsRecordedRight(self):
    item = PublicItem()
    assertEqual([item], public_items)

def testTwoPublicItemsAreRecordedRight(self):
    item1 = PublicItem()
    item2 = PublicItem()
    assertEqual([item1, item2], public_items)

如果public_items是一个神奇的列表，应该被神奇地填充为调用魔法函数PublicItem的副作用，那么在setUp中调用后者实际上会破坏正确地测试这些简单的案例，所以我当然不会这样做！

如何在编写测试时处理setUp（）成瘾？

2 个答案: