Является ли тестирование изнутри приложения с помощью встроенных сценариев хорошей идеей?

Question

Я работаю над большой программой с графическим интерфейсом, и даже после нескольких лет разработки у меня до сих пор нет ни одного тестового примера. Я убрал много потребностей, используя Eiffel вместе с дисциплинированным кодированием и Design By Contract.

Но иногда я чувствую, что проведение юнит-тестов может помочь мне. Но всякий раз, когда я пытаюсь что-то записать, я скоро сталкиваюсь с проблемой тестирования GUI (ИМХО все еще остается проблемой на стороне исследования), и попытка изолировать код от среды кажется еще более сложной.

Думайте о моей работе как о написании очень сложных плагинов для чего-то вроде Eclipse.

Итак, моя новая идея - добавить в приложение интерфейс сценариев Lua и запускать тесты внутри программы вместо отдельных модульных тестов. Или мне действительно стоит потратить много часов на рефакторинг (и написание макетов объектов), чтобы обеспечить возможность модульного тестирования приложения?

Answer 1

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

• Скорость выполнения: автоматизация графического интерфейса с использованием внешнего инструмента обычно очень медленная. Встроенный механизм сценариев, хотя и не такой быстрый, как модульные тесты во время компиляции, будет намного быстрее, чем GUI-тесты.
• Не изобретать велосипед: при создании тестовых каркасов GUI вам часто приходится копировать логику приложения в тестовом коде. С помощью скриптового движка вы можете просто вызвать код напрямую.
• Безголовое выполнение. При автоматизации тестирования GUI агенту, на котором вы выполняете тест, потребуется рабочий стол с графическим интерфейсом, который имеет определенные ограничения при попытке отправки тестовых заданий на другие машины (требуется интерактивный вход в систему, экран не заблокирован, и т. д.) При кодировании API с помощью механизма сценариев это не проблема.

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

Answer 2

На мой взгляд, любой подход к тестированию будет:

• Дайте вам большую уверенность в своем коде, а
• Улучшение качества продукта

... стоит сделать.

Модульное тестирование является лишь средством для достижения цели.

Если ваша интуиция говорит вам, что написание тестов на встроенном Lua даст вам максимальную отдачу, я скажу, что сделайте это.

Answer 3

Сценарии - довольно плохой выбор для тестирования, так как:

1. он не будет отлавливать фактические ошибки интеграции GUI или GUI-to-model-code
2. будет много, много ошибок интеграции скриптов в код
3. это очень медленный и неэффективный способ тестирования ошибок кода модели
4. Для настройки и обслуживания требуется больше работы, чем для любого возможного модульного тестирования

Если у вас есть сценарии в вашем продукте по какой-то другой причине, тогда тестирование, очевидно, необходимо. Но это почти никогда не будет победой, если добавить ее исключительно для тестирования.

Юнит-тесты (или интеграционные тесты в стиле юнитов), вероятно, являются наиболее очевидной альтернативой. Другие:

• Автоматизация графического интерфейса продукта или инструмента на основе воспроизведения и записи.
• Сценарии GUI, которые похожи на сценарии приложений, но это модель GUI, а не приложение, которое выполняет работу по поддержке сценариев, и, надеюсь, выбранный вами инструментарий уже сделал это.
• Тестовое кодирование на основе графического интерфейса, похожее на сценарии графического интерфейса, но на вашем основном языке разработки: вы пишете код, который заполняет текстовые поля, нажимает кнопки и т. Д.

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