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

19. Сервируем стол (метод setUp) 
Начав писать тесты, вы обнаружите, что д ействуете в рамках
некоторой общей по след овательно сти (Билл Уэйк (Bill Wake) прид умал
сокращение 3A – 
Arrange, Act, Assert
):
• вначале вы созд аете некоторые тестовые объекты – 
Arrange
;
• затем заставляете эти объекты д ействовать – 
Act
;
• потом проверяете результаты их работы – 
Assert
.
Вызов тестового метод а
Вызов метода setUp перед обращением к методу
Вызов метод а tearDown по сле обращения к метод у
Метод tearDown д олжен вызываться д аже в случае неуд ачи теста
Выполнение нескольких тестов
Отчет о результатах
Первый этап – 
Arrange
– зачастую совпад ает д ля нескольких разных
тестов, в то время как второй и третий этапы д ля разных тестов
различаются. У меня есть д ва числа: 7 и 9. Если я сложу их, я д олжен
получить 16; если я вычту второе из первого, я ожид аю получить –2;
наконец, если я перемножу их, я полагаю, д олжно получиться 63.
Операции и ожид аемые результаты различаются, од нако исход ные
д анные од ни и те же – д ва числа: 7 и 9.
Если под обное повторяется раз за разом в разных масштабах (а вед ь
так оно и есть), мы д олжны под умать о том, как можно оптимизировать
созд ание тестовых объектов. Возникает конфликт межд у след ующими
д вумя ограничениями:
Производительность
. Мы хотим, чтобы тесты срабатывали как
можно быстрее. Отсюд а след ует, что если од ни и те же объекты
используются в нескольких тестах, желательно, чтобы созд ание этих
объектов выполняло сь всего од ин раз.
 Изоляция
. Успех или неуд ача од ного теста никак не д олжны влиять
на работу д ругих тестов. Если несколько тестов используют од ни и те
же объекты и если од ин из тестов меняет внутреннее со стояние какого-
либо объекта, результаты работы о стальных тестов, скорее всего,
изменятся.
Взаимозависимо сть межд у тестами привод ит к од ному весьма

---

неприятному эффекту: если од ин тест перестает работать, о стальные
д есять тестов тоже перестают работать, несмотря на то, что
тестируемый ими код выполняется правильно. Характерен также и
д ругой, еще более неприятный эффект, когд а поряд ок выполнения
тестов имеет значение: если я запускаю тест A перед тестом Б, оба теста
выполняются успешно, если я запускаю тест Б перед тестом А, тест А не
выполняется. Или, еще хуже, код , проверяемый тестом Б, д ействует
неправильно, од нако из-за того, что тест А запускается перед тестом Б,
тест Б выполняется успешно.
Итак, мы хотим избежать взаимозависимо сти межд у тестами.
Пред положим, что мы можем сд елать процед уру созд ания объектов
д о статочно быстрой. В этом случае мы могли бы созд авать объекты д ля
теста кажд ый раз перед выполнением очеред ного теста. Этот под ход в
замаскированном вид е уже использовался нами в классе WasRun, в
котором требовало сь, чтобы перед запуском теста флаг wasRun
сбрасывался в со стояние «ложь». Напишем тест: