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

TestCaseTest
def testRunning(self):
test = WasRun("testMethod")
test.run()
assert(test.wasRun)
Мы также можем упро стить сами тесты. В обоих случаях мы
созд аем экземпляр класса WasRun, а вед ь зад ача созд ания тестовых
объектов возлагается на под готовительный этап – именно об этом мы с
вами говорили. Стало быть, мы можем созд ать объект WasRun в метод е
setUp(), а затем использовать его в тестовых метод ах. Кажд ый тестовый
метод выполняется в отд ельном экземпляре класса TestCaseTest, поэтому

---

д ва разных теста не могут быть взаимозависимы. (Мы исход им из того,
что объект не буд ет взаимод ействовать с внешним миром некоторым
непред усмотренным урод ливым спо собом, например путем изменения
значений глобальных переменных.)
TestCaseTest
def setUp(self):
self.test = WasRun("testMethod")
def testRunning(self):
self.test.run()
assert(self.test.wasRun)
def testSetUp(self):
self.test.run()
assert(self.test.wasSetUp)
Вызов тестового метод а
Вызов метод а setUp перед обращением к метод у
Вызов метод а tearDown по сле обращения к метод у
Метод tearDown д олжен вызываться д аже в случае неуд ачи теста
Выполнение нескольких тестов
Отчет о результатах
Теперь сд елаем так, чтобы по сле выполнения тестового метод а
обязательно выполнялся метод tearDown().
В д анной главе мы
• решили, что на текущий момент тестов важнее про стота, чем их
производ ительно сть;
• написали тест д ля метод а setUp() и реализовали этот метод ;
• использовали метод setUp(), чтобы упро стить тестируемый
объект-контейнер теста;
• 
использовали 
метод
setUp(), 
чтобы 
упро стить 
тесты,
проверяющие созд анный нами тестовый объект (я же говорил, что
временами 
это 
напоминает 
нейрохирургическую 
операцию 
на
собственном мозге).

---