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

Самошунтирование (Self Shunt)
Как можно убед иться в том, что од ин объект корректно

---

взаимод ействует 
с 
д ругим? 
Заставьте 
тестируемый 
объект
взаимод ействовать не с целевым объектом, а с вашим тестом.
Пред положим, что вы хотите д инамически обновлять зеленую
поло су, отображаемую в рамках тестируемого пользовательского
интерфейса. Если мы сможем под ключить наш объект к объекту
TestResult, значит, мы сможем получать оповещения о запуске теста, о
том, что тест не сработал, а также о том, что весь набор тестов начал
работу или, наоборот, завершил работу. Кажд ый раз, получив
оповещение о запуске теста, мы можем выполнить обновление
интерфейса. Вот соответствующий тест:
ResultListenerTest
def testNotification(self):
result = TestResult()
listener = ResultListener()
result.addListener(listener)
WasRun("testMethod"). run(result)
assert 1 == listener.count
Тест нужд ается в объекте, который под считывал бы количество
оповещений:
ResultListener
class ResultListener:
def __init__(self):
self.count = 0
def startTest(self):
self.count = self.count + 1
Под ожд ите-ка! Зачем нам нужен отд ельный объект Listener? Все
необход имые функции мы можем возложить на объект TestCase. В этом
случае объект TestCase становится под обием под д ельного объекта.
ResultListenerTest
def testNotification(self):
self.count = 0
result = TestResult()
result.addListener(self)
WasRun("testMethod"). run(result)

---

assert 1 == self.count
def startTest(self):
self.count = self.count + 1
Тесты, 
написанные 
с 
использованием 
шаблона
«Самошунтирование» (Self Shunt), как правило, читаются лучше, чем
тесты, написанные без него. Пред ыд ущий тест является неплохим
примером. Счетчик был равен 0, а затем стал равен 1. Вы можете
про след ить за по след овательно стью д ействий прямо в код е теста.
Почему счетчик стал равен 1? Очевид но, кто-то обратился к метод у
startTest(). Гд е произошло обращение к метод у startTest()? Это произошло
в начале выполнения теста. Вторая версия теста использует д ва разных
значения переменной count в од ном месте, в то время как первая версия
присваивает переменной count значение 0 в од ном классе и проверяет эту
переменную на равенство значению 1 в д ругом.
Возможно, при использовании шаблона «Самошунтирование» (Self
Shunt) вам потребуется применить шаблон рефакторинга «Выд еление
интерфейса» (Extract Interface), чтобы получить интерфейс, который
д олжен быть реализован вашим тестом. Вы д олжны сами опред елить,
что проще: выд еление интерфейса или тестирование существующего
объекта в рамках концепции «черный ящик». Од нако я часто замечал,
что интерфейсы, выд еленные при выполнении самошунтирования, в
д альнейшем, как правило, оказываются полезными д ля решения д ругих
зад ач.
В результате использования шаблона «Самошунтирование» (Self
Shunt) вы можете наблюд ать, как тесты в языке Java обрастают
разнообразными 
причуд ливыми 
интерфейсами. 
В 
языках 
с
оптимистической типизацией класс теста обязан реализовать только те
операции интерфейса, которые д ействительно используются в процессе
выполнения теста. Од нако в Java вы обязаны реализовать абсолютно все
операции интерфейса несмотря на то, что некоторые из них буд ут
пустыми. По этой причине интерфейсы след ует д елать как можно менее
емкими. Реализация кажд ой операции д олжна либо возвращать значение,
либо генерировать исключение – это зависит от того, каким образом вы
хотите быть оповещены о том, что произошло нечто неожид анное.