Сегодня про один из самых надежных и стабильных элементов формы. Про поле ввода с типом перечисление.
Действительно, у перечисления есть некий ореол стабильности. Что может «сломаться» в списке значений, который недоступен для изменения пользователю?
Так же согласитесь, что, в большинстве случаев, перечисления проверяются «незаметно» в рамках других проверок. Например, перечисление хозяйственных операций документа обязательно будут проверены в тестах по созданию документа с каждой хозяйственной операцией.
Возможно, данный факт «незаметной проверки» и влияет на создание ореола стабильности. То есть, я хочу сказать, что обычно перечисления не проверяются отдельно выделенными сценариями.
Но, как показал опыт, и на перечисления найдутся свои ошибки.
Что же это за ошибка?
Есть типовая конфигурация. В ней есть справочник, одним из элементов которого является поле ввода с типом перечисление. Коллекция значений выгладит следующим образом:
- Значение №1
- Значение №2
- Значение №3
И есть отраслевая конфигурация, разработанная на данной типовой. Соответственно в ней так же присутствует данный справочник. А вот коллекция значений перечисления программно увеличена и имеет следующий вид:
- Значение №1
- Значение №2
- Значение №3
- Значение №4
- Значение №5
- Значение №6
Первые три значения перечисления остаются от типовой конфигурации, а вторая тройка программно дополняется отраслевыми значениями.
При очередном обновлении отраслевой конфигурации на типовую произошла следующая ситуация: значения перечисления от типовой конфигурации остались и задвоились, а отраслевые значения затерлись:
- Значение №1
- Значение №2
- Значение №3
- Значение №1
- Значение №2
- Значение №3
Чтобы избежать такой ошибки в будущем, необходимо проверять коллекцию значений перечисления для данной ситуации.
Как проверять?
Всегда начинать стоит с поиска подходящего функционала в рабочем инструменте. Но в конфигурации «1С:Сценарное тестирование» нет специализированного шага для проверки перечислений. Впрочем, это не означает, что проверки сделать нельзя.
Думаю, что самый надежный способ проверки для данного случая уже пришел вам очевидной мыслью. Но не будем ее озвучивать сразу, а немного поразмышляем.
Итак, как же можно построить проверку в данной ситуации?
Первое, это проверять только по количеству элементов.
Знаем, что в коллекции перечисления шесть значений и логично ожидаем, что их будет шесть. Но представленный выше пример удачно показательный, так как типовых значений перечисления три и отраслевых тоже три. Три плюс три равняется шесть. Соответственно проверка пройдет успешно и тест не выявит ошибки задвоения типовых значений и исчезновение отраслевых.
Второе, это проверка только по значениям элементов.
В данном случае, тест выявит ошибку. Ожидаются все шесть значений перечисления, а по факту есть только три типовых, которые повторяются. Но и здесь присутствует ненадежность. Скажем, если бы все шесть значений присутствовали, а одно повторялось два раза, то получилась бы следующая картинка:
- Значение №1
- Значение №2
- Значение №3
- Значение №4
- Значение №5
- Значение №6
- Значение №6
Тогда тест не выявит ошибки задвоения одного из значений и тест пройдет успешно.
Сразу вспоминаем первый способ проверки только по количеству. И понимаем, что нужно соединять проверки по количеству и значениям.
Третье, это объединить обе проверки в одну: и по количеству и по значениям.
Тут возвращаемся к нашей очевидной мысли, смысл которой заключается в сравнении с эталоном. Думаю, что именно она оказалась самой первой, как прыткий покупатель у дверей магазина в день распродажи. Занимала еще ночью. Тот, кто сейчас подумал: «Ну, я же сразу об этом догадался. Я молодец!» Да, вы молодец! Осталось только реализовать.
Сравнение с эталоном
Что же нужно сделать для реализации сравнения с эталоном:
- Получить все значения перечисления
- Вывести их в табличный документ
- Сохранить табличный документ в формате MXL
- Подготовить эталонный MXL, в котором будут все верные значения перечисления
- Сравнить два файла MXL: эталонный и текущий
Данный способ хочется отметить еще и за то, что из данной последовательности действий можно сформировать макрошаг, определив в нем параметрами имя перечисления и путь к месту выгрузки MXL файла. Таким способом получиться универсальная конструкция в виде одного макрошага, который можно применять для проверки любого перечисления.
Отлично!
Но данный способ хранит в себе два момента, в которых, на мой взгляд, могут затаиться слабые места.
Первый момент проявляется, если нет навыка программирования. Придется либо разбираться самостоятельно, либо просить коллег разработчиков написать код для создания табличного документа со значениями перечисления. Соответственно есть вероятность потерять время на реализацию.
Второй, это возникновение промежуточного файла. Возможно, я сильно помешан на компактности, но люблю, когда инструмент работает «внутри себя». И если эталонные значения храниться непосредственно в шаге сценария тестирования, то текущие значения надо выгрузить в отдельный файл, специально выделять какой-то каталог под его хранение и управлять его гигиеной. Конечно, данный способ самый распространенный, какие-то временные файлы создаются и удаляются постоянно. Но если появляется возможность избежать создания промежуточной сущности, то лучше ей воспользоваться.
Потому рассмотрим еще один способ проверки, который, как видно из названия статьи, связан с выводом информации в пользовательские сообщения.
Проверка через сообщения пользователю
Надо признать, что и в данном способе придется писать код. Но здесь его будет совсем мало, если сравнивать с подготовкой сравнения с эталоном.
Итак, суть данного способа заключается в следующих действиях:
1. Вывести каждое значение перечисления в отдельном сообщении пользователя.
Для этого необходимо выбрать шаг «Процедура на встроенном языке» с настройками выполнения «в тестируемом приложении» и «на сервере». Добавляем в него следующий код:
ЗначенияПеречисления = Перечисления.<Имя перечисления>;
Для Индекс = 0 По ЗначенияПеречисления.Количество() - 1 Цикл
Сообщить(ЗначенияПеречисления.Получить(Индекс));
КонецЦикла;
Вместо конструкции <Имя перечисления> указывается необходимое имя перечисления, которое придется брать из Конфигуратора. Для этого в меню элемента формы (три вертикальные точки) выбираем команду «Информация для технического специалиста».
И получаем имя нужной нам формы, чтобы не блуждать в многообразии метаданных конфигурации.
Переходим в Конфигуратор, открываем свойства нужного реквизита и забираем имя перечисления из значения «Тип».
При выполнении автоматического теста клиент тестирования обязательно запускается со шлюзом тестирования, так как в нем будет исполняться код из шага «Процедура на встроенном языке», а так же на его форме будут выведены пользовательские сообщения.
2. Далее необходимо сравнить количество сообщений с ожидаемым.
Дальнейшие проверки будут производится при помощи шага «Сообщения».
Сравнение количества выведенных сообщений осуществляется через действие «Проверить количество сообщений пользователю». Соответственно в нем указывается то количество сообщений, которое реально ожидается.
3. Далее нужно убедиться, что в выводимых сообщениях присутствуют все необходимые значения.
Снова повторяем шаг «Сообщения», но уже с действием «Проверить текст сообщений пользователю».
Добавляем шаг столько раз, сколько в коллекции перечисления значений.
4. И можно закрыть все сообщения.
Закрывать сообщения не обязательно. Во-первых, они никак не мешают автоматической проверке. Во-вторых, это лишний шаг, который увеличивает время работы теста. Но, если вы по природе своей эстет и считаете, что сотая доля секунды при выполнении теста вполне уместна, то закрываются все сообщения шагом «Сообщения» с действием «Закрыть окно сообщений».
По своей сути, такая проверка, это аналог сравнения с эталоном. Только текущие проверяемые значения не сохраняется в промежуточный файл, а выводится в виде сообщений пользователю.
При этом страдает компактность и универсализация: в одном перечислении может быть два значения, а в другом десять. Соответственно, для первого случая будет четыре шага в сценарии тестирования: вывод значений перечисления в сообщения, проверка количества, проверка первого значения, проверка второго значения. А во втором случае, двенадцать шагов из-за количества значений перечисления.
Но, как было сказано в начале статьи, перечисления специально проверяются редко, потому такой способ может быть вполне применим без стремления к универсализации.
А главное, он реализуется быстро и с минимальным кодированием.
В общем, в зависимости от решаемых задач можно пойти разными способами:
- если мест, которые требуют проверки перечислений много, то можно потратить время и сделать один универсальный макрошаг и использовать его.
- если проверяемых перечислений мало, то вполне можно проверять через вывод их значений в сообщения пользователю.
