Модульное тестирование приложений MFC UI?

Ответ 1

Это зависит от того, как структурировано приложение. Если логический и графический интерфейс разделены (MVC), то тестирование логики легко. Взгляните на Michael Feathers "Скромное диалоговое окно" (PDF).

EDIT: Если вы думаете об этом: вы должны очень тщательно реорганизовать, если приложение не структурировано таким образом. Другого метода тестирования логики нет. Скрипты, имитирующие клики, просто царапают поверхность.

На самом деле это довольно просто:

Предположим, что ваш элемент управления/окно/независимо изменяет содержимое списка, когда пользователь нажимает кнопку, и вы хотите убедиться, что список содержит нужные вещи после нажатия.

• Рефакторинг, чтобы был отдельный список с элементами для отображения списка. Элементы хранятся в списке и не извлекаются из того, откуда поступают ваши данные. Код, который делает список списка вещей, знает только о новом списке.
• Затем вы создадите новый объект контроллера, который будет содержать логический код. Метод, который обрабатывает нажатие кнопки, вызывает только mycontroller- > ButtonWasClicked(). Он не знает о списке или других вещах.
• MyController:: ButtonWasClicked() делает то, что нужно сделать для предполагаемой логики, подготавливает список элементов и сообщает обновлению элемента управления. Для этого вам нужно отделить контроллер и управление, создав для этого интерфейс (чистый виртуальный класс). Контроллер знает только объект этого типа, а не элемент управления.

Вот оно. Контроллер содержит логический код и знает управление только через интерфейс. Теперь вы можете написать обычный unit test для MyController:: ButtonWasClicked(), высмеивая элемент управления. Если вы не знаете, о чем я говорю, прочитайте статью Майклса. Дважды. И снова после этого.
(Примечание для себя: должно учиться не так много).

Ответ 2

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

Теперь то, что я собираюсь предложить, - это определенно тяжелая работа.. но с некоторой дисциплиной и настойчивостью вы скоро увидите это преимущество.

• Сначала вам понадобится поддержка управления для новых исправлений, чтобы немного поработать. Убедитесь, что все понимают, почему.
• Затем купите копию WELC book. Прочтите его на обложку, если у вас есть время. Или, если вам трудно, отсканируйте индекс, чтобы найти симптом, который демонстрирует ваше приложение. Эта книга содержит много хороших советов и именно то, что вам нужно, пытаясь получить существующий код для тестирования. alt text http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL160_AA115_.jpg
• Затем для каждого нового исправления/изменения потратить некоторое время и понять область, над которой вы собираетесь работать. Напишите несколько тестов в выбранном вами варианте xUnit (свободно доступный) для осуществления текущего поведения.
• Убедитесь, что все тесты прошли. Напишите новый тест, который требует необходимого поведения или ошибки.
• Введите код, чтобы сделать этот последний тестовый проход.
• Рефтор безжалостно находится в зоне испытаний, чтобы улучшить дизайн.
• Повторите все изменения, которые вы должны внести в систему здесь. Никаких исключений из этого правила.
• Теперь обетованная земля: Скоро появятся все растущие острова хорошо протестированного кода. Все больше и больше кода будет подпадать под автоматизированный набор тестов, и изменения будут постепенно упрощаться. И это потому, что медленно и верно базовый дизайн становится более проверяемым.

Простым выходом был мой предыдущий ответ. Это трудный, но правильный выход.

Ответ 3

Хотя это не идеально, лучшее, что я нашел для этого, - это AutoIt http://www.autoitscript.com/autoit3

"AutoIt v3 - это бесплатный скриптовый язык, основанный на BASIC, предназначенный для автоматизации графического интерфейса Windows и общего сценария. Он использует комбинацию имитируемых нажатий клавиш, движения мыши и манипулирования окнами/элементами управления, чтобы автоматизировать задачи таким образом, который невозможно или надежный с другими языками (например, VBScript и SendKeys). AutoIt также очень мал, автономный и будет работать на всех версиях Windows из коробки без каких-либо раздражающих" сроков выполнения"!

Это хорошо работает, когда у вас есть доступ к исходному коду запускаемого приложения, поскольку вы можете использовать идентификатор ресурса элементов управления, которые хотите управлять. Таким образом, вам не нужно беспокоиться о симуляции щелчков мыши на определенные пиксели. К сожалению, в устаревшем приложении вы можете обнаружить, что идентификатор ресурса не уникален, что может вызвать проблемы. Однако. очень просто изменить идентификаторы, чтобы быть уникальными и перестраивать.

Другая проблема заключается в том, что вы столкнетесь с проблемами синхронизации. У меня нет проверенного и правильного решения. Пробная и ошибка - это то, что я использовал, но это явно не масштабируемо. Проблема заключается в том, что AutoIT script должен ждать, пока тестовое приложение ответит на команду перед тем, как script выдает следующую команду или проверяет правильный ответ. Иногда нелегко найти удобное событие для ожидания и просмотра.

Я чувствую, что при разработке нового приложения я бы настаивал на последовательном сигнале "ГОТОВ". Это было бы полезно для пользователей пользователей, а также для тестовых скриптов! Это может быть проблемой для устаревшего приложения, но, возможно, вы можете ввести его в проблемные моменты и медленно распространить его на все приложение, поскольку техническое обслуживание продолжается.

Ответ 4

Хотя он не может обрабатывать сторону пользовательского интерфейса, я unit test код MFC, используя библиотеку Boost Test. Существует статья Code Project о начале работы:

Разработка надежных объектов с Boost

Ответ 5

Я понимаю, что это датированный вопрос, но для тех из нас, кто по-прежнему работает с MFC, платформа Microsoft С++ Unit Testing Framework в VS2012 работает хорошо.

Общая процедура:

• Скомпилируйте проект MFC как статическую библиотеку
• Добавьте новый проект Native Unit Test в ваше решение.
• В тестовом проекте добавьте проект MFC в качестве ссылки.
• В свойствах конфигурации тестового проекта добавьте каталоги Include для ваших файлов заголовков.
• В компоновщике параметры ввода добавляют ваш MFC.lib; nafxcwd.lib; libcmtd.lib;
• В разделе "Игнорировать конкретные библиотеки по умолчанию" добавьте nafxcwd.lib; libcmtd.lib;
• В разделе "Общие" укажите расположение экспортированного вами файла библиотеки MFC.

fooobar.com/questions/190009/... содержит хорошее описание того, зачем вам нужны nafxcwd.lib и libcmtd.lib.

Другая важная вещь, которую нужно проверить в старых проектах. В свойствах общей конфигурации убедитесь, что оба проекта используют один и тот же набор символов. Если ваш MFC использует многобайтовый набор символов, вам понадобится MS Test, чтобы это сделать.

Ответ 6

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

• Мы используем Rational Robot для проведения тестов на дым и т.д.

• Другим подходом, который имел некоторый успех, является создание небольшого языка, специфичного для продукта, и script тесты, которые используют VBScript, а некоторые управляющие - шпионскую магию. Включите общие действия в команды. OpenDatabase будет командой, которая, в свою очередь, введет необходимые блоки script, чтобы щелкнуть Главное меню > Файл > "Открыть...". Затем вы создаете листы excel, которые представляют собой серию таких команд. Эти команды также могут принимать параметры. Что-то вроде теста FIT, но больше работы. После того, как вы найдете большинство общих команд и готовых скриптов. Он выбирает и собирает сценарии (помеченные CommandID) для написания новых тестов. Тест-лингер анализирует эти листы Excel, объединяет все маленькие script блоки в тест script и запускает его.

  • OpenDatabase "C:\tests\MyDB"
  • OpenDialog "Добавить модель"
  • AddModel "M0001", "MyModel", 2.5, 100
  • PressOK
  • SaveDatabase

НТН

Ответ 7

На самом деле мы использовали Rational Team Test, а затем Robot, но в недавних обсуждениях с Rational мы обнаружили, что они не планируют поддерживать Native x64-приложения, больше ориентированные на .NET, поэтому мы решили переключить автоматизированные инструменты QA. Это замечательно, но расходы на лицензирование не позволяют нам включить его для всех разработчиков.

Все наши приложения поддерживают COM API для скриптинга, который мы тестируем с помощью VB, но это проверяет API как приложение как таковое.

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