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

TestCase
class TestCase:
pass
WasRun
class WasRun(TestCase):.
Теперь переместим атрибут name из под класса в суперкласс:
TestCase
def __init__(self, name):
self.name = name
WasRun
def __init__(self, name):
self.wasRun = None
TestCase.__init__(self, name)
Наконец, замечаем, что метод run() использует только атрибуты
суперкласса, значит, скорее всего, он д олжен располагаться в
суперклассе. (Я всегд а стараюсь размещать операции ряд ом с д анными.)

---

TestCase
def __init__(self, name):
self.name= name
def run(self):
method = getattr(self, self.name)
method()
Естественно, межд у выполнениями этих мод ификаций я кажд ый раз
запускаю тесты, чтобы убед иться, что все работает как над о.
Нам над оело смотреть на то, как наша программа кажд ый раз
печатает од но и то же: None и 1. Использовав разработанный механизм,
мы можем теперь написать:
TestCaseTest
class TestCaseTest(TestCase):
def testRunning(self):
test = WasRun("testMethod")
assert(not test.wasRun)
test.run()
assert(test.wasRun)
TestCaseTest("testRunning"). run()
Вызов тестового метод а
Вызов метод а setUp перед обращением к метод у
Вызов метод а tearDown по сле обращения к метод у
Метод tearDown д олжен вызываться д аже в случае неуд ачи теста
Выполнение нескольких тестов
Отчет о результатах
Серд цем этого теста являются операторы print, превращенные в
выражения assert, таким образом, вы можете вид еть, что выполненная
нами процед ура – это усложненный шаблон рефакторинга «Выд еление
метод а» (Extract Method).
Я открою вам маленький секрет. Шажки, которыми мы д вигались от
теста к тесту в д анной главе, выгляд ят смехотворно маленькими.
Од нако д о того, как получить пред ставленный результат, я пытался
выполнить разработку более крупными шагами и потратил на это около
шести часов (конечно, мне пришло сь тратить д ополнительное время на
изучение тонко стей языка Python). Я д ва раза начинал с нуля и кажд ый

---

раз д умал, что мой код сработает, од нако этого не происход ило. Я понял,
что попытка пропустить самый начальный, самый примитивный этап
разработки, – это грубейшее нарушение принципов TDD.
Конечно же, вы не обязаны по стоянно перемещаться такими
лилипутскими шажками. По сле того как вы о своите TDD, вы сможете
д вигаться вперед более уверенно, реализуя межд у тестами значительно
больший объем функционально сти. Од нако чтобы в совершенстве
о своить TDD, вы д олжны научиться перемещаться маленькими
шажками тогд а, когд а это необход имо.
Далее мы планируем перейти к решению зад ачи обращения к метод у
setUp(). Од нако вначале под вед ем итог.
В д анной главе мы
• поняли, как начать работу со смехотворно малюсенького шага;
• реализовали функционально сть путем созд ания фиксированного
код а, а затем обобщения этого код а путем замены констант на
переменные;
• использовали шаблон «Встраиваемый переключатель» (Pluggable
Selector) и д али себе обещание не использовать его вновь в течение как
минимум четырех месяцев, так как он существенно усложняет анализ
код а;
• начали работу над инфраструктурой тестирования маленькими
шажками.

---