Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Бек К. -> "Экстремальное программирование: разработка через тестирование " -> 35

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 29 30 31 32 33 34 < 35 > 36 37 38 39 40 41 .. 81 >> Следующая


TestCaseTest

def setUp(self):

self, test= WasRunC'testMethod") def testRunning(self):

self .test.runO

assert(self.test.wasRun) def testSetUp(self):

self .test.runO

assert(self.test.wasSetUp)

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

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

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

Метод tearDown должен быть вызван даже в случае, если тестовый метод

не сработал

Выполнение нескольких тестов Отчет о результатах

Теперь сделаем так, чтобы после выполнения тестового метода обязательно выполнялся метод tearDownQ.

Глава 19 • Сервируем стол (метод setup) 107

В данной главе мы:

• решили, что на текущий момент простота тестов важнее, чем их производительность;

• написали тест для метода setUp() и реализовали этот метод;

• использовали метод setUp() для того, чтобы упростить тестируемый объект-контейнер теста;

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

Убираем

со стола (метод

tearDown)

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

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

Метод tearDown должен быть вызван даже в случае, если тестовый метод не сработал Выполнение нескольких тестов Отчет о результатах

Иногда для выполнения теста требуется выделить некоторые внешние ресурсы. Очевидно, что связанные с этим операции должны выполняться в теле метода setUp(). Если мы хотим, чтобы тесты были независимыми друг от друга, мы должны позаботиться об освобождении этих ресурсов. Для выполнения связанных с этим операций предлагаю использовать специальный метод tearDown(), который будет автоматически выполняться после завершения теста.

Каким образом можно протестировать выполнение метода tearDown()? Упрощенный способ — использовать еще один флаг. Однако все эти флаги начинают сбивать меня с толку. Если мы будем использовать флаги, мы упустим один очень важный аспект: метод setUp() должен быть выполнен непосредственно перед обращением к тестовому методу, а метод tearDown() — непосредственно после обращения к тестовому методу. Чтобы проверить это обстоятельство, я намерен изменить стратегию тестирования. Я предлагаю создать миниатюрный журнал, в котором будет отмечаться последовательность выполнения методов. Каждый метод будет добавлять в конец журнала соответствующую запись. Таким образом, просмотрев журнал, мы сможем установить порядок выполнения методов.

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

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

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

Метод tearDown должен быть вызван даже в случае, если тестовый метод

не сработал

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

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

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

WasRun

def setUpCself): self.wasRun= None self.wasSetUp= 1 self.log= "setup "

Теперь мы можем изменить метод testSetUpO, чтобы вместо флага он проверял содержимое журнала:

TestCaseTest

def testSetl)p(self): self .test.runO

assert("setup " -= self.test.log)

После этого мы можем удалить флаг wasSetUp. Мы также можем добавить в журнал запись о выполнении метода:

WasRun

def testMethod(self): self.wasRun= 1

self.log= self.log + "testMethod "

В результате нарушается работа теста testSetUpQ, так как в момент выполнения этого метода журнал содержит строку "setup testMethod ". Изменяем ожидаемое значение:

TestCaseTest

def testSetUp(self): self .test.runO

assertC'setUp testMethod " == self.test.log)

Теперь этот тест выполняет работу обоих тестов, поэтому мы можем удалить testRunning и переименовать testSetUp:

TestCaseTest

def setUp(self):

self, test = WasRunC'testMethod") def testTemplateMethod(self):

self .test.runO assert("setUp testMethod " == test.log)

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

TestCaseTest

def testTemplateMethod(self): test= WasRunC'testMethod") test.runO

assertC'setUp testMethod " == test.log)

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

копиться достаточное количество оснований, указывающих на необходимость рефакторинга, иными словами, они оттягивают выполнение рефакторинга, чтобы быть полностью уверенными в его необходимости. Они поступают так потому, что не любят аннулировать результаты проделанной работы. Однако я предпочитаю не отвлекаться на рассуждения о том, не придется ли в будущем отменять тот или иной рефакторинг, который необходим мне в настоящем. Вместо этого я предпочитаю сосредоточиться на дизайне. По этой причине я рефлекторно делаю рефакторинг тогда, когда считаю нужным, ни капли не опасаясь того, что сразу же после этого мне, возможно, придется отменить его.
Предыдущая << 1 .. 29 30 31 32 33 34 < 35 > 36 37 38 39 40 41 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100