Кодированное тестирование пользовательского интерфейса: какова причина создания нескольких отдельных классов UIMap вместо нескольких частичных классов UIMap?

Question

Я работаю над проектом, который включает в себя «полу-большой» графический интерфейс приложения. Есть около 4-5 отдельных (сложных) страниц, на которых я хочу выполнить Coded UI Tests, и у меня сложилось впечатление, что создание нескольких UIMaps - это путь! Источники: UIMap container, Using multiple UIMaps, More source и список можно продолжить ...

Моя проблема/мысль: Использование нескольких UIMaps это «хорошо», потому что:

1. позволяет более категоризированный структуру кода
2. позволяет упростить сотрудничество между разработчиками
3. делает код менее сложным для обслуживания.

Но почему нет один просто раскалывая UIMap в нескольких частичных классов? Разве у него не было бы таких же преимуществ? Еще дальше: наличие UIMap в частичных классах не позволит разработчику (мне) добавить сложность в код, например UIMap container.

Answer 1

Этот вопрос не имеет особого отношения к CodedUI. Использование частичных классов для симуляции разделения беспокойства - не правильный путь.

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

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

Частицы используются, когда класс является частью сгенерированной части кода кода, не сгенерированной или написанной на разных языках (например, xaml и C# для SL/WPF). Различные биты могут охватывать части одного и того же поведения, поэтому имеет смысл (с точки зрения SoC) группировать их под одним и тем же классом, но с точки зрения управления кодами две части необходимо разделить. Вот почему CodedUI использует partials (файлы * .Designer.cs генерируются, а файлы * .cs - нет).

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

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

Answer 2

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

• UI Карты трудно очистить. По мере того, как набор тестов развивается, карта пользовательского интерфейса становится все более старыми и неиспользуемыми. Практически нет поддержки для безопасного удаления нежелательных предметов.

• Наличие множества карт пользовательского интерфейса означает, что различные разработчики тестов могут быть продуктивными одновременно, не генерируя конфликтующие элементы в основной карте пользовательского интерфейса. Хотя файл «.uimap» представляет собой простой текстовый файл, он содержит XML. Успешное слияние этих файлов в общем виде с системами управления конфигурацией будет где-то между очень сложным и невозможным.

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

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

• Big UI Maps потребляют много памяти и процессорного времени. Анекдотически использование большой карты пользовательского интерфейса может сделать тестовый пакет очень медленным (у меня нет реальных доказательств этого). Большая карта пользовательского интерфейса имеет большое количество членов и вложенных классов. Легко представить, что данные времени выполнения, необходимые для управления таким классом, являются большими и потребляют много циклов памяти и процессора.

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