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

Отчет о результатах
Строка журнала в классе WasRun
Метод tearDown() д олжен выполняться, д аже когд а в процессе
выполнения теста возникло исключение. Од нако чтобы д обиться этого,
мы д олжны перехватывать исключения. (Честно говоря, я уже пытался
реализовать это, но у меня не получило сь, и я вернул все на свои места.)
Если при реализации перехвата исключений мы д опустим ошибку, мы
можем не заметить этого, так как станд артный механизм д оклад а об
исключениях не буд ет функционировать.
Работая в стиле TDD, важно понимать, что о собое значение имеет
поряд ок, в котором вы реализуете тесты. Выбирая тест, над которым я
буд у работать д альше, я стараюсь выбрать тот, который, во-первых,
по служит д ля меня источником новых знаний, а во-вторых, д о статочно
про ст, чтобы я был уверен в том, что могу заставить его работать. Если
я д обиваюсь успешного выполнения этого теста, но захожу в тупик при
реализации след ующего, я вполне могу выполнить откат назад на д ва
шага. Было бы неплохо, если бы сред а разработки оказывала мне в этом
помощь. Например, было бы неплохо, если бы в момент срабатывания
всех тестов автоматически созд авалась резервная копия всего исход ного
код а, с которым я работаю.
По сле выполнения всех тестов желательно получить информацию о
том, как они выполнились, например: «запущено 5, неуд ачных 2:
TestCaseTest.testFooBar – ZeroDivideException, MoneyTest.testNegation –
AssertionError». Если тесты перестают выполняться или результаты
перестают отображаться на экране мы, по крайней мере, сможем
обнаружить ошибку. Од нако наша инфраструктура не обязана знать обо
всех разработанных тестах.
Пусть метод TestCase.run() возвращает объект класса TestResult с
результатами выполнения теста (вначале тест буд ет только од ин, од нако

---

позже мы усовершенствуем этот объект).