Книга: Экстремальное программирование. Разработка через тестирование

23. Оформляем тесты в набор

23. Оформляем тесты в набор

Вызов тестового метода

Вызов метода setUp перед обращением к методу

Вызов метода tearDown после обращения к методу

Метод tearDown должен вызываться даже в случае неудачи теста

Выполнение нескольких тестов

Отчет о результатах

Строка журнала в классе WasRun

Отчет о неудачных тестах

Перехват и отчет об ошибках setUp

Мы не можем оставить работу над xUnit, не реализовав класс TestSuite, представляющий собой набор тестов. Конец нашего файла, где мы запускаем все наши тесты, выглядит весьма неопрятно:

print(TestCaseTest(«testTemplateMethod»). run(). summary())

print(TestCaseTest("testResult"). run(). summary())

print(TestCaseTest("testFailedResultFormatting"). run(). summary())

print(TestCaseTest("testFailedResult"). run(). summary())

Дублирование – это всегда плохо, за исключением случаев, когда вы используете его в качестве мотивации для поиска недостающего элемента дизайна. В данном случае нам хотелось бы сгруппировать тесты и запустить их при помощи одной команды. (Мы приложили массу усилий для изоляции тестов, однако все эти усилия не окупят себя, если мы будем запускать тесты по одному.) Еще одна хорошая причина, по которой было бы неплохо реализовать TestSuite, заключается в том, что этот класс хорошо демонстрирует использование шаблона «Компоновщик» (Composite), – мы хотим, чтобы набор тестов вел себя в точности так же, как единичный тест.

Мы хотим обладать возможностью создать набор тестов (объект TestSuite), добавить в него несколько тестов и получить общий результат выполнения всех этих тестов:

TestCaseTest

def testSuite(self):

suite = TestSuite()

suite.add(WasRun("testMethod"))

suite.add(WasRun("testBrokenMethod"))

result = suite.run()

assert("2 run, 1 failed" == result.summary())

Для успешного выполнения теста создадим в объекте TestSuite список тестов и реализуем метод add(), который просто добавляет тест, переданный в качестве аргумента, в список:

TestSuite

class TestSuite:

def __init__(self):

self.tests = []

def add(self, test):

self.tests.append(test)

(В языке Python оператор [] создает пустую коллекцию.)

Однако с реализацией метода run() возникают проблемы. Мы хотим, чтобы результаты срабатывания всех тестов накапливались в едином объекте класса TestResult. Таким образом, мы можем написать следующий код:

TestSuite

def run(self):

result = TestResult()

for test in tests:

test.run(result)

return result

Здесь оператор цикла «for test in tests» выполняет итерации по всем элементам последовательности tests, присваивает их по одному переменной цикла test и запускает соответствующий тест. Однако шаблон «Компоновщик» (Composite) подразумевает, что набор объектов должен обладать точно таким же интерфейсом, каким обладает отдельный объект. Если мы передаем параметр методу TestCase.run(), значит, мы должны передавать точно такой же параметр методу TestSuite.run(). Можно использовать одну из трех альтернатив.

• Воспользоваться встроенным в язык Python механизмом параметров со значениями по умолчанию. К сожалению, значение параметра по умолчанию вычисляется во время компиляции, но не во время выполнения, а мы не хотим повторно использовать один и тот же объект TestResult.

• Разделить метод на две части – одна создает объект TestResult, а вторая выполняет тест, используя переданный ей объект TestResult. Я не могу придумать хороших имен для двух частей метода, а это означает, что данная стратегия не является самой лучшей.

• Создавать объекты TestResult в вызывающем коде.

Мы будем создавать объекты TestResult в вызывающем коде. Этот шаблон называется «Накапливающий параметр» (Collecting Parameter).

TestCaseTest

def testSuite(self):

suite = TestSuite()

suite.add(WasRun("testMethod"))

suite.add(WasRun("testBrokenMethod"))

result = TestResult()

suite.run(result)

assert("2 run, 1 failed" == result.summary())

При использовании данного подхода метод run() не возвращает никакого явного значения:

TestSuite

def run(self, result):

for test in tests:

test.run(result)

TestCase

def run(self, result):

result.testStarted()

self.setUp()

try:

method = getattr(self, self.name)

method()

except:

result.testFailed()

self.tearDown()

Теперь мы можем облагородить обращение к тестовым методам в конце файла:

suite = TestSuite()

suite.add(TestCaseTest("testTemplateMethod"))

suite.add(TestCaseTest("testResult"))

suite.add(TestCaseTest("testFailedResultFormatting"))

suite.add(TestCaseTest("testFailedResult"))

suite.add(TestCaseTest("testSuite"))

result = TestResult()

suite.run(result)

print(result.summary())

Вызов тестового метода

Вызов метода setUp перед обращением к методу

Вызов метода tearDown после обращения к методу

Метод tearDown должен вызываться даже в случае неудачи теста

Выполнение нескольких тестов

Отчет о результатах

Строка журнала в классе WasRun

Отчет о неудачных тестах

Перехват и отчет об ошибках setUp

Создать объект TestSuite автоматически на основе класса TestCase

Здесь слишком много повторяющегося кода, от которого можно избавиться, если обеспечить способ конструирования набора тестов автоматически, исходя из предоставленного класса TestCase.

Однако вначале восстановим корректное выполнение четырех не неудачных тестов (эти тесты используют старый интерфейс функции run() без аргументов):

TestCaseTest

def testTemplateMethod(self):

test = WasRun("testMethod")

result = TestResult()

test.run(result)

assert("setUp testMethod tearDown " == test.log)

def testResult(self):

test = WasRun("testMethod")

result = TestResult()

test.run(result)

assert("1 run, 0 failed" == result.summary())

def testFailedResult(self):

test = WasRun("testBrokenMethod")

result = TestResult()

test.run(result)

assert("1 run, 1 failed" == result.summary())

def testFailedResultFormatting(self):

result = TestResult()

result.testStarted()

result.testFailed()

assert("1 run, 1 failed" == result.summary())

Обратите внимание, что каждый из тестов создает экземпляр класса TestResult – эту операцию можно выполнить однократно внутри метода setUp(). Благодаря реализации этой идеи мы упростим тесты, однако сделаем их несколько более сложными в прочтении:

TestCaseTest

def setUp(self):

self.result = TestResult()

def testTemplateMethod(self):

test = WasRun("testMethod")

test.run(self.result)

assert("setUp testMethod tearDown " == test.log)

def testResult(self):

test = WasRun("testMethod")

test.run(self.result)

assert("1 run, 0 failed" == self.result.summary())

def testFailedResult(self):

test = WasRun("testBrokenMethod")

test.run(self.result)

assert("1 run, 1 failed" == self.result.summary())

def testFailedResultFormatting(self):

self.result.testStarted()

self.result.testFailed()

assert("1 run, 1 failed" == self.result.summary())

def testSuite(self):

suite = TestSuite()

suite.add(WasRun("testMethod"))

suite.add(WasRun("testBrokenMethod"))

suite.run(self.result)

assert("2 run, 1 failed" == self.result.summary())

Вызов тестового метода

Вызов метода setUp перед обращением к методу

Вызов метода tearDown после обращения к методу

Метод tearDown должен вызываться даже в случае неудачи теста

Выполнение нескольких тестов

Отчет о результатах

Строка журнала в классе WasRun

Отчет о неудачных тестах

Перехват и отчет об ошибках setUp

Создать объект TestSuite автоматически на основе класса TestCase

Все эти бесчисленные ссылки self выглядят ужасно, однако без этого в языке Python никак не обойтись. Если бы этот язык изначально был объектно-ориентированным, наверное, в этих ссылках не было бы надобности, а ссылки на глобальные переменные требовали бы квалификации. Однако язык Python изначально является интерпретируемым языком с добавленной в него поддержкой объектов (надо отметить, что поддержка объектов в этом языке реализована великолепно). В результате по умолчанию переменные считаются глобальными, а явные ссылки на self – необходимыми.

Я оставляю реализацию оставшихся пунктов вам в качестве упражнения. Надеюсь, обретенные навыки работы в стиле TDD помогут вам.

Чтобы подвести итог, напомню, что в данной главе мы

• написали тест для класса TestSuite;

• написали часть реализации, однако не добились успешного выполнения тестов – это нарушение правил (я уверен, что существует простая поддельная реализация, которая заставила бы тесты работать, благодаря чему мы могли бы выполнять рефакторинг, имея перед глазами зеленую полоску, однако сейчас я не хочу думать на эту тему);

• изменили интерфейс метода run(), благодаря чему набор тестов можно использовать точно так же, как и отдельный тест, – в результате тесты наконец выполнились успешно;

• выполнили рефакторинг имеющихся тестов – переместили общий код создания объекта результатов в метод setUp().

Оглавление книги