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

 

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

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

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


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

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

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

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

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

Строка журі юла о клоссс WasRun

Теперь мы готовы к реализации метода tearDown(). Ага! Опять я вас поймал! Теперь мы готовы к тестированию метода tearDown():

TestCaseTest

def testTemplateMethod(self): test= WasRun("testMethod") test.runC)

assert("setup testMethod tearDown " — test.log)

Он не срабатывает. Чтобы заставить его работать, выполняем несложные добавления:

TestCase

def runCself. result): result. testStartedO self.setUpO

method = getattr(self. self.name)

method O

self .tea rDownO

WasRun

def setUp(self):

self.log= "setup " def testMethod(self):

self.log= self.log + "testMethod " def tearDown(self):

self.log= self.log + "tearDown "

Неожиданно мы получаем ошибку не в классе WasRun, а в классе TestCaseTest У нас нет «пустой» реализации метода tearDown() в классе TestCase:

TestCase

def tearDown(self): pass

Мы начинаем получать пользу от инфраструктуры, которую мы разрабатываем. Замечательно! Никакого рефакторинга не требуется. Очевидная реализация, созданная нами после обнаружения ошибки, сработала, и код получился чистым.

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

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

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

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

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

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

Далее мы перейдем к формированию отчета о результатах выполнения тестов. Вместо использования встроенного в Python механизма обработки ошибок мы планируем реализовать и использовать собственный механизм наблюдения за срабатыванием тестов.

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

• перешли от использования флагов к использованию журнала;

• создали тесты для метода tearDown() и реализовали этот метод с использованием нового механизма протоколирования;

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

Учет

и контроль

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

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

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

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

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

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

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

Работая в стиле TDD важно понимать, что особое значение имеет порядок, в котором вы реализуете тесты. Выбирая тест, над которым я буду работать дальше, я стараюсь выбрать тест, который, во-первых, послужит для меня источником новых знаний, а во-вторых, достаточно прост, чтобы я был уверен в том, что могу заставить его работать. Если я добиваюсь срабатывания этого теста, однако захожу в тупик при реализации следующего теста, я вполне могу выполнить откат назад на два шага. Было бы неплохо, если бы среда разработки оказывала мне в этом помощь. Например, было бы неплохо, если бы в момент срабатывания всех тестов автоматически создавалась резервная копия всего исходного кода, с которым я работаю.

После выполнения всех тестов мы хотели бы получить информацию о том, как они сработали, например: «запущено 5, не сработало 2: TestCaseTest.testFoo-Ваг — ZeroDivideException, MoneyTest.testNegation — AssertionError». Если тесты перестают выполняться или результаты перестают отображаться на экране, по крайней мере мы сможем обнаружить ошибку. Однако наша инфраструктура не обязана знать обо всех разработанных тестах.

Пусть метод TestCase.run() возвращает объект класса TestResult, который будет хранить в себе результаты выполнения теста (в начале тест будет только один, однако позже мы усовершенствуем этот объект).

TestCaseTest

def testResult(self):

test= WasRun("testMethod") result= test.runO

assertC'l run. 0 failed" == result.summaryO) Начнем с поддельной реализации:

TestResult

class TestResult: def summary(self):

return "1 run, 0 failed"

Теперь сделаем так, что объект класса TestResult возвращается в результате выполнения метода TestCase. run():

TestCase

def run(self): self.setUpO

method = getattr(self. self.name)

method ()

self.tearDown()

return TestResultO

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