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

Как вы тестируете большое приложение MFC UI?

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

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

Я слышал о таких методах, как скрытые тестовые кнопки в диалогах, которые появляются только в отладочных сборках, есть ли для этого стандартные наборы инструментов.

среда-C++/C/FORTRAN, MSVC 2005, Intel FORTRAN 9.1, Windows XP / Vista x86 & x64.

17
c++ mfc tdd unit-testing user-interface

7 ответов

Это зависит от того, как приложение структурировано. Если логика и код GUI разделены (MVC), то тестирование логики легко. Взгляните на Майкла перышки "Скромное Диалоговое Окно" (PDF).

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

Это на самом деле довольно легко:

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

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

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

12

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

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

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

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

13

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

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

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

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

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

3

Я понимаю, что это устаревший вопрос, но для тех из нас, кто все еще работает с MFC, платформа модульного тестирования Microsoft C++ в VS2012 работает хорошо.

Общий Порядок:

  1. скомпилируйте свой проект MFC как статическую библиотеку
  2. добавьте в решение новый собственный проект модульного тестирования.
  3. в тестовом проекте добавьте проект MFC в качестве ссылки.
  4. в свойствах конфигурации тестового проекта, добавить Включите каталоги для заголовочных файлов.
  5. в компоновщике параметры ввода добавляют ваш MFC.lib; nafxcwd.Либ;библиотеку libcmtd.lib;
  6. в разделе "игнорировать определенные библиотеки по умолчанию" добавьте nafxcwd.Либ;библиотеку libcmtd.lib;
  7. в разделе Общие добавьте местоположение экспортированного файла lib MFC.

https://stackoverflow.com/questions/1146338/error-lnk2005-new-and-delete-already-defined-in-libcmtd-libnew-obj имеет хорошее описание почему вам нужно nafxcwd.Либ и библиотеку libcmtd.движение за освобождение.

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

3

хотя он не может обрабатывать сторону пользовательского интерфейса, I модульный тестовый код MFC с помощью библиотеки тестов Boost. Существует статья проекта кода о начале работы:

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

2

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

  • мы используем:Рациональное Робот делаю тесты и тому подобное.

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

    1. OpenDatabase "C:\tests\MyDB"
    2. OpenDialog "Добавить Модель"
    3. AddModel "M0001", "MyModel", 2.5, 100
    4. PressOK
    5. SaveDatabase

HTH

1

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

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

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

0