Архитектура Шаблона "посетитель" поблочного тестирования
Оператор import x делает две вещи *
- Он загружает (и запускает) модуль, на который ссылаются, если он еще не был
- Он назначает модуль для переменная с тем же именем
Ваша функция назначает модуль something только переменной something, когда a == 1. Если a != 1, даже если модуль был загружен , он не назначен переменной, поэтому на него нельзя ссылаться.
Вот почему то, что вы делаете, терпит неудачу. Именно поэтому то, что вы пытаетесь сделать, не дает вам абсолютно никаких преимуществ, поскольку модули загружаются и запускаются только при первом импорте. Каждый последующий раз просто делаю шаг 2.
Причина, по которой ваш код не ссылается на глобальный something, заключается в том, что python переопределяет глобальные имена, если локальная переменная с тем же именем появляется в любом месте функции, даже если она никогда не достигается. Следующая функция f не работает так же, как ваша.
x = 1
def f(y):
if False:
x = y
return x
Решение состоит в том, чтобы не использовать x как локальную, так и глобальную переменную.
3 ответа
заставьте тестового посетителя возразить, и заставлять его посетить вещи.... тестируют это, это посетило правильные вещи.
Можно создать фиктивные объекты и сделать, чтобы посетители посетили их и затем создали ложных посетителей и тест, что правильные действия были выполнены.
Поблочное тестирование не действительно о тестировании шаблонов, это о тестировании корректной реализации методов и функций. Шаблон "посетитель" является определенной структурой класса, и для каждого из классов (ConcreteVisitor и ConcreteElement, конкретно) включил, Вы захотите модульные тесты.
При разработке уверенности, что методы класса ведут себя хорошо, Вы могли использовать свою платформу модульного теста для разработки интеграционных тестов также. Не запускайте интеграционное тестирование rightaway: Вы найдете разработку большого количества интеграционных тестов, которые на самом деле тестируют поведение определенного класса, т.е. модульные тесты.
Нуждаетесь ли Вы в фиктивных объектах или можете использовать 'реальные' объекты, другой разговор. Это во многом зависит от того, ведут ли объекты себя достаточно хорошие в целях модульного теста (т.е. они не вытягивают в большом количестве дополнительных зависимостей и т.д.), и являются ли сами объекты протестированной единицей (т.е. необходимо смочь доверять этим объектам 100%). Насмешка по сравнению с реальной проблемой объектов была обращена на stackflow прежде, так ищите теги unittest.