Как бороться с зависимостью setUp () при написании тестов?

Question

Я немного новичок в написании тестов. Я испытываю трудности с поддержанием чистоты и краткости моего набора, вместо этого пытаясь добиться слишком многого с помощью uber-setUp.

Мой вопрос: как вы разбили тестирование?

Включают ли ваши тесты одну или две строки независимого пошагового кода?

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

или вы учитываете это в setUp несмотря ни на что?

Если это так, как вы справляетесь с разделением тестовых классов? Создаете ли вы новый класс, когда один набор тестов требует другого набора, чем другой набор тестов?

Answer 1

Я полагаю, что вы ударили пару анти-паттернов здесь

• Чрезмерная настройка
• Неправильно разделенный прибор.

Практическое правило заключается в том, что для всех тестов в конкретном тестовом устройстве необходим код в методе 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 фактически уничтожил бы способность правильно проверять эти простые случаи, так что, конечно, я бы этого не сделал!