автоматизация тестирования visual c++ 2010 приложения

Здравствуй, сообщество.
Посоветуйте пожалуйста наиболее подходящий инструмент для приложения, написанном на visual c++ 2010
Спасибо!

Какого тестирования?
Модульного?
Функционального?
Производительности?

Какого тестирования?
Модульного?
Функционального?
Производительности?

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

C++ 2010, к сожалению, ни о чем не говорит.
Через что работает приложение: графический интерфейс? веб? консоль? голый API?
Если GUI, то какой тип контролов: стандартные или MFC? WinForms? WPF? другое?

Через что работает приложение: графический интерфейс? веб? консоль? голый API?
Если GUI, то какой тип контролов: стандартные или MFC? WinForms? WPF? другое?

GUI, тип контролов MFC. Но проблему составляет самописный грид. Хотя и стандартные элементы
тоже странно себя ведут. Интересует инструмент, который может работать именно с внутренними свойствами объектов, т.к. у грида стандартных нет.
Пока пробовал TestComplete - сборка "открытого" приложения не помогла.
Может есть другие инструменты, которые легко получают доступ к внутренним методам/свойствам?

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

Давайте посмотрим, что нам говорит первый же раздел:
1) У контролов, производных от MFC, доступны свойства, которые унаследованы у стандартных предков.
2) Если собрать приложение с отладочной инфой, будет доступна куча внутренних свойств контролов.
Вывод: если грид нарисован на канвасе, с использованием каких-то внутренних объектов данных, ничего мы с этого не получим.
Надо писать производный контрол, и открывать в нем свойства, которые дают доступ к данным.

Другой подход - сделать COM-интерфейс к приложению. Тогда можно использовать любые бесплатные средства, например AutoIt, который будет нормально работать с обычными контролами, а с вашим гридом - через COM.

В любом случае, если не хотите верифицировать тесты через скриншоты, нужны доделки со стороны разработчиков.

Из своего опыта. У нас есть одно приложение (MFC), в котором на форме куча разнообразных элементов, и все рисуются на канвасе. Тяжелое наследие миграции из DOS'а. От его автоматизации мы отказались. Благо, работает оно на редкость стабильно.
В другом случае (правда, там не MFC, поэтому готовой схемой поделиться не могу) у нас тоже был рисованный грид. Причем автоматизация требовалась позарез. В итоге по согласованию с менеджментом завели критический баг, и под него разработчики полностью переписали контрол: добавили в него свойства, дающие доступ к внутренним данным.

На самом деле подумайте, стоит ли всё усложнять. Если кейсы несложные и воспроизводимые, можно обойтись и скриншотами.

Вы, наверное, уже видели, но ...

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