Как проводить тесты пользовательского интерфейса с кодировкой?

Мне удобно записывать закодированные тесты пользовательского интерфейса с помощью VS2010 Ultimate.

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

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

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

Что происходит в файле ответов и как я могу создать свой собственный в формате XML, чтобы вводить значения, вводимые в текстовые поля, при воспроизведении закодированного теста пользовательского интерфейса?

Будем признательны за любые ссылки и рекомендации!


visual-studio-2010 c# tdd coded-ui-tests
person bleepzter    schedule 22.02.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Отказ от ответственности: не фанат CodedUI.

Link1 - Создание теста CodedUI на основе данных

Должна быть возможность использовать запись n-replay для генерации теста CodedUI. Затем внесите изменения, перечисленные выше, чтобы управлять им с помощью входов из набора входов.

Однако я не уверен, что повторная запись теста уничтожит ваши модификации ... Вам нужно попробовать это и посмотреть. Если вам это нужно, я бы посоветовал использовать CodedUI в режиме сценария (вместо записи и воспроизведения).

person Gishu    schedule 29.02.2012
comment
Повторная запись закодированных тестов пользовательского интерфейса не уничтожит файлы ответов XML. Содержимое этих файлов хранится в объекте TestContext.DataRow, поэтому, если вы повторно запишите тест, вам просто нужно изменить код теста, чтобы использовать хранящиеся в нем переменные. - person bleepzter; 06.03.2012
comment
Также я не знал формата файлов XML. Методом проб и ошибок я придумал общую структуру: <TestDefinition><TestRun><variable1/><variable2/><variable3/></TestRun></TestDefinition>. Похоже, построитель закодированных источников данных теста пользовательского интерфейса ищет XML-файл и позволяет вам выбрать тег <TestRun/> в качестве источника данных. Единственное, что меня действительно беспокоит, - это то, почему и как встраивать целые объекты, а не однозначные переменные в тег <TestRun>. Я имею в виду, что я всегда могу разграничить что-то внутри строки через канал |, но встраивание полного объекта было бы круто. - person bleepzter; 06.03.2012

arrow_upward
1
arrow_downward

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

Если вы хотите перейти к более автоматизированному тестированию UAT, для этого есть инструменты. Не уверен в Silverlight / WPF как таковом (поскольку я не трачу много времени на то, чтобы вынести всю бизнес-логику из битов пользовательского интерфейса), но я полагаю, что он должен быть.

person Gregory A Beamer    schedule 22.02.2012
comment
Отделение бизнес-логики от пользовательского интерфейса называется модульным тестом, при котором разработчик обычно тестирует использование шаблона типа MVC или MVVM. Я провожу интеграционное тестирование, когда целые рабочие процессы тестируются в нескольких границах системы. Моки не сокращают его, потому что это системные тесты, из которых программное обеспечение получает заявления о приемке и соответствии. - person bleepzter; 23.02.2012
comment
Извините, я передумал. Я хотел бы отдать вам должное за то, что, по крайней мере, вы знаете теорию тестирования, хотя первые два более низких уровня тестирования. Любой ввод является положительным, даже если он напрямую не решает проблему, и после долгой ночи возни я понял, как это сделать сам. - person bleepzter; 23.02.2012
comment
Интеграционное тестирование может быть UAT или закодировано с использованием набора модульных тестов. Обычно в моих решениях две библиотеки: AssemblyName.Test.Integration и AssemblyName.Test.Unit. Оба используют MSTest в качестве примера, но один проверяет стек. Не проверяйте пользовательский интерфейс, потому что это очень тонкий слой без логики. Следуя этому принципу, тестирование UI - это UAT, а не интеграция. И есть наборы для автоматизации частей пользовательского интерфейса. Я полагаю, вы могли бы также использовать их для интеграции, если это необходимо. - person Gregory A Beamer; 23.02.2012
comment
Важная часть - убедиться, что в пользовательском интерфейсе нет бизнес-логики. Однажды я работал над умным клиентским приложением, и они утверждали, что логика должна быть в умном клиенте. Верно, но не в долбанном .exe файле. У вас все еще может быть умный клиент с библиотеками. Оставьте биты пользовательского интерфейса чистыми и сделайте так, чтобы они сосредоточились на отображении данных и взаимодействии с пользователем. Когда вы будете строго придерживаться этого правила, вы легко сможете написать код интеграционных тестов. Возможная проблема: вам нужен согласованный набор данных для ваших тестов. Мне лично сейчас нравится управление лабораторией в команде VS, но раньше я делал это иначе. - person Gregory A Beamer; 23.02.2012
comment
Вы определенно правы. Однако сценарии, с которыми я работаю, немного сложнее. Пример: компонент 1 отправляет данные компоненту два, где оба компонента находятся на двух разных машинах. В то время как компонент два принимает данные, он также выполняет с ними операции обработки данных и изменяет их в соответствии с бизнес-правилами. Отправка данных через компонент 1 осуществляется с помощью закодированного теста пользовательского интерфейса, в котором тест взаимодействует с пользовательским интерфейсом отправителя. Тест также проверяет, как данные обрабатываются компонентом два, извлекая данные из SQL и проверяя их содержимое. - person bleepzter; 23.02.2012
comment
В приведенном выше примере компонент 1 - это то, с чем предварительно записанный тест пользовательского интерфейса взаимодействует физически. Поскольку каждый тестер может иметь разные настройки в отношении конфигурации как первого, так и второго компонентов, при воспроизведении этапов выполнения теста также должна быть возможность использовать предоставленный файл ответов, предпочтительно в формате XML. Файл ответов будет иметь настройки для каждого поля ввода, используемого первым компонентом, строку подключения к базе данных второго компонента и т.д. -компилированные компоненты, используемые в сборке - person bleepzter; 23.02.2012