Тестирование кода GUI: мне использовать библиотеку-макет?

Question

Недавно я экспериментировал с TDD при разработке приложения с графическим интерфейсом на Python. Я нахожу очень обнадеживающим иметь тесты, которые проверяют функциональность моего кода, но было сложно следовать некоторым рекомендованным методам TDD. А именно, сначала было сложно писать тесты. И я затрудняюсь сделать свои тесты читабельными (из-за широкого использования насмешливой библиотеки).

Я выбрал библиотеку-насмешку под названием mocker . Я часто его использую, поскольку большая часть кода, который я тестирую, вызывает (а) другие методы в моем приложении, которые зависят от состояния системы или (б) объекты ObjC / Cocoa, которые не могут существовать без цикла событий и т. Д.

Во всяком случае, у меня есть много тестов, которые выглядят так:

def test_current_window_controller():
    def test(config):
        ac = AppController()
        m = Mocker()
        ac.iter_window_controllers = iwc = m.replace(ac.iter_window_controllers)
        expect(iwc()).result(iter(config))
        with m:
            result = ac.current_window_controller()
            assert result == (config[0] if config else None)
    yield test, []
    yield test, [0]
    yield test, [1, 0]

Обратите внимание, что на самом деле это три теста; все используют одну и ту же параметризованную функцию тестирования. Вот код, который тестируется:

def current_window_controller(self):
    try:
        # iter_window_controllers() iterates in z-order starting
        # with the controller of the top-most window
        # assumption: the top-most window is the "current" one
        wc = self.iter_window_controllers().next()
    except StopIteration:
        return None
    return wc

Одна из вещей, которые я заметил при использовании mocker, заключается в том, что сначала проще написать код приложения, а затем вернуться назад и написать тесты, так как большую часть времени я высмеиваю многие вызовы методов и синтаксис для написать поддельные вызовы гораздо более многословно (поэтому сложнее написать), чем код приложения. Проще написать код приложения, а затем смоделировать тестовый код.

Я считаю, что с помощью этого метода тестирования (и немного дисциплины) я могу легко написать код со 100% охватом тестирования.

Мне интересно, являются ли эти тесты хорошими тестами? Буду ли я сожалеть о том, что сделал это так в будущем, когда, наконец, обнаружу секрет написания хороших тестов?

Я так сильно нарушаю основные принципы TDD, что мои тесты напрасны?

Answer 1

Если вы пишете свои тесты после того, как написали свой код и выполнили его, вы не выполняете TDD (и при этом вы не получаете никаких преимуществ от разработки в первую очередь или на основе тестирования). проверить ТАК вопросы для окончательных книг по TDD)

Одна из вещей, с которыми я заметил с помощью пересмешника является то, что легче сначала напишите код приложения и затем вернитесь и напишите тесты во-вторых, так как большую часть времени я издеваться над многими вызовами методов и тому Синтаксис для написания смоделированных вызовов гораздо более многословный (таким образом, труднее написать), чем код приложения. Это проще написать код приложения, а затем смоделируйте тестовый код этого.

Конечно, это проще, потому что вы просто проверяете, что небо оранжевое после того, как вы сделали его оранжевым, нарисовав его кистью определенного типа. Это тесты дооснащения (для уверенности в себе). Шутки хороши, но вы должны знать, как и когда их использовать - как говорится: «Когда у тебя молоток, все выглядит как гвоздь». Также легко написать целый набор нечитаемых и не столь полезных, как может тесты Время, потраченное на понимание сути теста, - это потерянное время, которое можно использовать для устранения неисправностей.

И дело в том:

• Чтение Насмешки - это не окурки - Мартин Фаулер , если вы этого еще не сделали. Google выявила несколько задокументированных примеров хороших ModelViewPresenter шаблонных графических интерфейсов (подделка / макетирование при необходимости).
• Изучите ваши варианты и выбирайте мудро. Я сыграю парня с ореолом на левом плече в белом, говорящего «Не делай этого». Прочтите этот вопрос относительно моих причин - Святой Джастин на вашем правом плече. Я верю, что ему есть что сказать :)

Answer 2

Пожалуйста, помните, что TDD - это не панацея. Это сложно, это должно быть сложно, и особенно сложно писать тесты для насмешек "заранее".

Так что я бы сказал - делай, что работает для тебя. Даже это не "сертифицированный TDD". Я делаю в основном то же самое.

Возможно, вы захотите предоставить свой собственный API для графического интерфейса, который будет находиться между кодом контроллера и кодом библиотеки GUI. Это может быть проще для насмешки, или вы можете даже добавить несколько проверочных хуков к нему.

И последнее, но не менее важное: ваш код не выглядит мне нечитаемым. Код, использующий макеты, обычно сложнее понять. К счастью, в Python издеваться намного проще и чище, чем на других языках.

Answer 3

Модульные тесты действительно полезны, когда вы реорганизуете код (т.е. полностью переписываете или перемещаете модуль). Пока у вас есть юнит-тесты до того, как вы внесете большие изменения, вы будете уверены, что не забыли переместить или включить что-нибудь, когда закончите.