Тестирование после рефакторинга платформеннозависимого кода

В финальной статье цикла материалов по докладу Александра Кириллова, руководителя группы разработки компании «ИТ-Экспертиза», с которым он выступил на конференции INFOSTART TECH EVENT 2024, рассмотрим особенности тестирования после завершения рефакторинга платформеннозависимого кода.

• 1 статья «Особенности работы информационных систем 1С под управлением Linux»
• 2 статья «Как проанализировать конфигурацию 1С на наличие платформеннозависимого кода»
• 3 статья «Подходы к рефакторингу платформеннозависимого кода»

Итак, мы закончили рефакторинг и теперь нужно убедиться, что доработки для ОС Linux не искажают исходную функциональность, работавшую для ОС Windows. Для этого проводим тестирование, используя смешанный подход в зависимости от контекста места обнаружения:

1. Unit-тесты – стараемся покрыть все места, где это возможно, используя расширение YAxUnit
2. Выполняем ручное тестирование везде, где это возможно.
3. Сценарное тестирование, как правило проводится уже заказчиками по их ПМИ, но при необходимости реализуем сценарии и проводим на нашей стороне, используем Vanessa Automation

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

Кроме того, нужно понимать, что при использовании различных операционных систем появляются разные комбинации клиентов и сервера. Как показывает практика, первым мигрирует сервер, позже – клиенты, и не всегда все одновременно. Поэтому тестирование необходимо выполнять во всевозможных комбинациях. Важно: комбинация «сервер Windows – клиенты Linux» на практике маловероятна, но если у заказчика она возможна, то нужно протестировать и ее.

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

1. Обновление релиза вендора. Несмотря на то, что в свежих релизах проводится работа над ошибками, нельзя полностью исключить риск появления платформеннозависимого кода.
2. Человеческий фактор. Если миграция еще не завершена, а сервер и клиенты работают под Windows, разработчики и тестировщики могут пренебрегать тестированием под Linux или попросту не иметь технической возможности его выполнить. В таком случае не исключено появление платформеннозависимого кода при реализации новой функциональности.

1. Контролировать исполнение стандартов разработки кроссплатформенных приложений: если производится автоматизированная проверка кода, нужно внести в правила требования от вендора – выполнять тщательное code-review.
2. Обязательно тестировать на ОС Linux, даже если в настоящее время базы работают под ОС Windows и переход только планируется. В любом случае необходимо подготовить тестовый стенд и выполнять тестирование на Linux.
3. Если по каким-то причинам обеспечить выполнение первых двух правил не получается, то после крупных изменений нужно провести промежуточный аудит и рефакторинг по его результатам.

1. Семь раз отмерь, один раз отрежь. По результатам аудита нужно провести столько встреч с заказчиком, сколько потребуется, чтобы окончательно определить состав мест для рефакторинга. При этом тщательно допросить заказчика – иногда выясняется, что часть функциональности не используется или используется очень редко, поэтому от нее можно смело отказаться.
2. Разделяй и властвуй. Чаще всего процесс миграции проходит в два этапа: сначала мигрирует сервер, потом клиенты. Поэтому рефакторинг лучше также проводить в два этапа: сначала обработать и проверить серверную часть, потом перейти к клиентской.
3. Не пытайся объять необъятное. Важно помнить, что не вся функциональность, которая содержит платформеннозависимый код, является критичной «здесь и сейчас». В первую очередь полезно проанализировать отчет по аудиту и обработать места обнаружения, связанные с важной функциональностью для пользователей. Все остальное можно доработать в процессе дальнейшей работы.
4. Если любишь – отпусти. При полной миграции (сервера и клиентов) высока вероятность, что какую-то часть функциональности заместить не получится. Кроме того, какие-то действия могут выполняться по-другому; к этому нужно быть готовым самим и заранее подготовить заказчика.
5. Не делай из мухи слона. Достаточно часто платформеннозависимый код может входить в состав сложных бизнес-процессов, но при этом функционально быть достаточно простым. Пример: маска при открытии файла, который дальше будет подписан и отправлен по ЭДО. Мы рекомендуем в таких случаях локализовать замещаемый код и тестировать только его, не занимаясь проверкой процесса целиком.
6. Век живи век учись. Платформа «1С:Предприятие» развивается очень быстро. С каждым релизом в ней появляется все больше и больше функций: работа с PDF, с буфером обмена, регулярные выражения и многое другое. Поэтому нужно внимательно следить за обновлениями платформы и отслеживать новые возможности, которые появляются в последнем релизе. Ну а там, где стандартной функциональности платформы не хватает, на помощь может прийти БСП, в которой вендором также реализовано много полезных функций.

1. Чтобы изучить текущее состояние конфигурации, проводим тщательный аудит по предложенным выше правилам.
2. После того, как определен перечень мест обнаружения платформеннозависимого кода, необходимо предметно обсудить с заказчиком объем работ и согласовать, какая именно функциональность нуждается в рефакторинге. Может оказаться, что часть обнаруженного не используется, а потому и брать в работу это не нужно.
3. Случается, что конфигурация содержит функции, которые невозможно заместить (с разумными трудозатратами). Поэтому нужно как можно раньше выявить такие места и принять решение. Чтобы в самый неподходящий момент не выяснилось, что какая-то функциональность ставит под угрозу всю миграцию или приводит к существенным задержкам реализации.
4. Важно сразу, как только будет принято решение о миграции на Linux, продумать и организовать процесс разработки новой функциональности с учетом рекомендаций по кроссплатформенности. Это позволит избежать повторных аудитов и незапланированных проблем при миграции.
5. Может оказаться, что визуально безобидный участок кода повлечет за собой большой объем работ. Например, потребуется реализация отсутствующих под ОС Linux компонентов. О таких нюансах лучше знать заранее, чтобы запланировать те или иные работы.
6. Требуется определить порядок миграции: обычно она начинается с сервера, а затем переносятся клиенты, но возможен сценарий единовременной миграции.
7. Объем работ нужно разбить на группы согласно приоритетам функциональности для пользователей. Если начать рефакторинг с критического функционала, то часть несущественных мест могут вообще отвалиться в процессе рефакторинга и тем самым упростить реализацию проекта.
8. Выполнять рефакторинг нужно по одной из приведенной ранее схем, а затем обязательно провести тестирование во всевозможных комбинациях клиента и сервера.
9. После завершения работ нужно проконтролировать дальнейшие доработки и при необходимости провести промежуточные аудиты; если миграция уже выполнена, проблем с этим возникнуть не должно.