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

TestCase
def run(self):
result = TestResult()
result.testStarted()
self.setUp()
try:
method = getattr(self, self.name)
method()
except:
result.testFailed()
self.tearDown()
return result
В этом код е присутствует од но тонкое место: если исключение
возникает во время выполнения метод а setUp(), оно не буд ет
перехвачено. Это означает, что в опред еленной степени тесты зависят
д руг от д руга. Од нако прежд е, чем менять код , мы д олжны написать
еще од ин тест. (Я научил мою старшую д очку Бетани программировать в
стиле TDD, когд а ей было 12 лет. Это самый первый стиль
программирования, с которым она познакомилась. Она не умеет
программировать иначе и абсолютно уверена, что д обавлять в

---

программу новый функциональный код можно только в случае, если
существует тест, который терпит неуд ачу. Од нако более опытные
программисты, как правило, вынужд ены напоминать себе о том, что
сначала необход имо писать тесты, а потом – код , заставляющий их
выполняться.) Я о ставляю этот след ующий тест и его реализацию вам в
качестве само стоятельного упражнения (мои пальцы опять устали):
Вызов тестового метод а
Вызов метод а setUp перед обращением к метод у
Вызов метод а tearDown по сле обращения к метод у
Метод tearDown д олжен вызываться д аже в случае неуд ачи теста
Выполнение нескольких тестов
Отчет о результатах
Строка журнала в классе WasRun
Отчет о неуд ачных тестах
Перехват и отчет об ошибках setUp
Далее мы сд елаем так, чтобы наша инфраструктура смогла
запустить несколько тестов под ряд .
В д анной главе мы
• обеспечили успешное выполнение нашего теста меньшего
масштаба;
• заново приступили к реализации более крупного теста;
• 
обеспечили 
успешное 
выполнение 
крупного 
теста,
во спользовавшись механизмом, реализованным д ля маленького теста;
• обратили внимание на потенциальную проблему, но вместо того,
чтобы немед ленно браться за ее решение, д обавили соответствующую
пометку в список зад ач.

---