UI-Automation тестирование запутанных приложений (WPF-)

Question

Мне было интересно, насколько сложно запускать UI-тесты, если код был запутан (особенно в отношении WPF-приложений при использовании тестовых фреймворков, которые получают доступ к свойствам автоматизации приложений и арантов, например, Ranorex, TestStudio, TestComplete, Squish, ...).

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

Можно утверждать, однако, что тесты должны выполняться на версии, которая фактически отправляется клиенту. Также, если мы используем сторонние компоненты как часть нашего SW, у нас может не быть роскоши использовать не-запутанную версию.

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

Answer 1

Я не могу говорить за других, но Ranorex полагается на UIA (UIAutomation), систему автоматизации и доступности, чтобы автоматизировать приложения WPF.

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

Единственными исключениями являются редкие случаи, когда вы явно настраиваете инструмент обфускации, чтобы обфускать строки, которые могут повлиять на МАУ, такие как прикрепленные свойства AutomationProperties.

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

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

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