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

TestCaseTest
def testSetUp(self):
test= WasRun("testMethod")
test.run()
assert(test.wasSetUp)
Чтобы запустить этот код , необход имо д обавить в конец нашего
файла строку TestCaseTest(«testSetUp»). run(). Интерпретатор вежливо
сообщает нам, что атрибут с именем wasSetUp отсутствует. И немуд рено,
вед ь мы пока еще не опред елили значение этого атрибута. Вот
необход имый д ля этого код :
WasRun
def setUp(self):
self.wasSetUp= 1
Од нако метод setUp() д олжен быть откуд а-то вызван. Обращение к
метод у setUp() – это работа класса TestCase. Добавим соответствующий
код :
TestCase
def setUp(self):

---

pass
def run(self):
self.setUp()
method = getattr(self, self.name)
method()
Чтобы заставить тест работать, мы сд елали целых д ва шага – это
слишком много, о собенно если учесть, что мы д вижемся почти
вслепую. Проверим, работает ли тест? Да, работает. Од нако если вы
хотите чему-то научиться, попробуйте прид умать, как мы можем
заставить тест работать, изменяя лишь по од ному метод у за од ин шаг.
Немед ленно во спользуемся новым механизмом, чтобы сократить
д лину наших тестов. Прежд е всего упро стим класс WasRun, д ля этого
перенесем процед уру установки флага wasRun в метод setUp():
WasRun
def setUp(self):
self.wasRun = None
self.wasSetUp = 1
Теперь можно упро стить метод testRunning() – о свобод ить его от
обязанно сти проверять со стояние флага перед вызовом тестового
метод а. Можем ли мы быть настолько уверенными в правильной работе
нашего код а? Только при условии, что в наборе тестов присутствует
тестовый метод testSetUp(). Это часто встречающийся шаблон – од ин
тест может быть про стым, только если в системе имеется д ругой тест,
выполняющийся успешно: