В последней статье цикла материалов по докладу Александра Кириллова, руководителя группы разработки компании «ИТ-Экспертиза», с которым он выступил на конференции INFOSTART TECH EVENT 2024, рассмотрим особенности тестирования после завершения рефакторинга платформеннозависимого кода.
С предыдущими материалами можно ознакомиться, кликнув на ссылки:
1 статья «Особенности работы информационных систем 1С под управлением Linux»
2 статья «Как проанализировать конфигурацию 1С на наличие платформеннозависимого кода»
3 статья «Подходы к рефакторингу платформеннозависимого кода»
* * *
Итак, мы закончили рефакторинг и теперь нужно убедиться, что доработки для ОС Linux не искажают исходную функциональность, работавшую для ОС Windows. Для этого проводим тестирование, используя смешанный подход в зависимости от контекста места обнаружения:
- Unit-тесты – стараемся покрыть все места, где это возможно, используя расширение YAxUnit
- Выполняем ручное тестирование везде, где это возможно.
- Сценарное тестирование, как правило проводится уже заказчиками по их ПМИ, но при необходимости реализуем сценарии и проводим на нашей стороне, используем Vanessa Automation
Чаще всего мы выбираем подход, минимизирующий затраты на тестирование, то есть, стараемся прицельно проверить измененную часть кода и убедиться, что поведение под Windows и Linux одинаковое. Полное функциональное тестирование проводим только в том случае, если изменения были существенные, и есть опасения в нарушении работы всего процесса.
Кроме того, нужно понимать, что при использовании различных операционных систем появляются разные комбинации клиентов и сервера. Как показывает практика, первым мигрирует сервер, позже – клиенты, и не всегда все одновременно. Поэтому тестирование необходимо выполнять во всевозможных комбинациях. Важно: комбинация «сервер Windows – клиенты Linux» на практике маловероятна, но если у заказчика она возможна, то нужно протестировать и ее.
Что дальше?
После того, как процесс рефакторинга завершен, а доработки протестированы и вошли в релиз, требуется поддерживать систему в актуальном состоянии и контролировать появление в ней платформеннозависимого кода, который может появиться по двум причинам:
- Обновление релиза вендора. Несмотря на то, что в свежих релизах проводится работа над ошибками, нельзя полностью исключить риск появления платформеннозависимого кода.
- Человеческий фактор. Если миграция еще не завершена, а сервер и клиенты работают под Windows, разработчики и тестировщики могут пренебрегать тестированием под Linux или попросту не иметь технической возможности его выполнить. В таком случае не исключено появление платформеннозависимого кода при реализации новой функциональности.
3 простых правила, соблюдение которых поможет избежать данных ситуаций:
- Контролировать исполнение стандартов разработки кроссплатформенных приложений: если производится автоматизированная проверка кода, нужно внести в правила требования от вендора – выполнять тщательное code-review.
- Обязательно тестировать на ОС Linux, даже если в настоящее время базы работают под ОС Windows и переход только планируется. В любом случае необходимо подготовить тестовый стенд и выполнять тестирование на Linux.
- Если по каким-то причинам обеспечить выполнение первых двух правил не получается, то после крупных изменений нужно провести промежуточный аудит и рефакторинг по его результатам.
Как избавляться от платформеннозависимого кода в конфигурациях заказчиков: 6 полезных советов
- Семь раз отмерь, один раз отрежь. По результатам аудита нужно провести столько встреч с заказчиком, сколько потребуется, чтобы окончательно определить состав мест для рефакторинга. При этом тщательно допросить заказчика – иногда выясняется, что часть функциональности не используется или используется очень редко, поэтому от нее можно смело отказаться.
- Разделяй и властвуй. Чаще всего процесс миграции проходит в два этапа: сначала мигрирует сервер, потом клиенты. Поэтому рефакторинг лучше также проводить в два этапа: сначала обработать и проверить серверную часть, потом перейти к клиентской.
- Не пытайся объять необъятное. Важно помнить, что не вся функциональность, которая содержит платформеннозависимый код, является критичной «здесь и сейчас». В первую очередь полезно проанализировать отчет по аудиту и обработать места обнаружения, связанные с важной функциональностью для пользователей. Все остальное можно доработать в процессе дальнейшей работы.
- Если любишь – отпусти. При полной миграции (сервера и клиентов) высока вероятность, что какую-то часть функциональности заместить не получится. Кроме того, какие-то действия могут выполняться по-другому; к этому нужно быть готовым самим и заранее подготовить заказчика.
- Не делай из мухи слона. Достаточно часто платформеннозависимый код может входить в состав сложных бизнес-процессов, но при этом функционально быть достаточно простым. Пример: маска при открытии файла, который дальше будет подписан и отправлен по ЭДО. Мы рекомендуем в таких случаях локализовать замещаемый код и тестировать только его, не занимаясь проверкой процесса целиком.
- Век живи век учись. Платформа «1С:Предприятие» развивается очень быстро. С каждым релизом в ней появляется все больше и больше функций: работа с PDF, с буфером обмена, регулярные выражения и многое другое. Поэтому нужно внимательно следить за обновлениями платформы и отслеживать новые возможности, которые появляются в последнем релизе. Ну а там, где стандартной функциональности платформы не хватает, на помощь может прийти БСП, в которой вендором также реализовано много полезных функций.
Чек-лист по импортозамещению
Делимся опытом, который получили на различных проектах и оформили в виде чек-листа по импортозамещению. Следуя ему можно получить высокий результат при ощутимой экономии времени и нервов.
Чтобы изучить текущее состояние конфигурации, проводим тщательный аудит по предложенным выше правилам.
- После того, как определен перечень мест обнаружения платформеннозависимого кода, необходимо предметно обсудить с заказчиком объем работ и согласовать, какая именно функциональность нуждается в рефакторинге. Может оказаться, что часть обнаруженного не используется, а потому и брать в работу это не нужно.
- Случается, что конфигурация содержит функции, которые невозможно заместить (с разумными трудозатратами). Поэтому нужно как можно раньше выявить такие места и принять решение. Чтобы в самый неподходящий момент не выяснилось, что какая-то функциональность ставит под угрозу всю миграцию или приводит к существенным задержкам реализации.
- Важно сразу, как только будет принято решение о миграции на Linux, продумать и организовать процесс разработки новой функциональности с учетом рекомендаций по кроссплатформенности. Это позволит избежать повторных аудитов и незапланированных проблем при миграции.
- Может оказаться, что визуально безобидный участок кода повлечет за собой большой объем работ. Например, потребуется реализация отсутствующих под ОС Linux компонентов. О таких нюансах лучше знать заранее, чтобы запланировать те или иные работы.
- Требуется определить порядок миграции: обычно она начинается с сервера, а затем переносятся клиенты, но возможен сценарий единовременной миграции.
- Объем работ нужно разбить на группы согласно приоритетам функциональности для пользователей. Если начать рефакторинг с критического функционала, то часть несущественных мест могут вообще отвалиться в процессе рефакторинга и тем самым упростить реализацию проекта.
- Выполнять рефакторинг нужно по одной из приведенной ранее схем, а затем обязательно провести тестирование во всевозможных комбинациях клиента и сервера.
- После завершения работ нужно проконтролировать дальнейшие доработки и при необходимости провести промежуточные аудиты; если миграция уже выполнена, проблем с этим возникнуть не должно.
С предыдущими материалами по докладу можно ознакомиться, кликнув на ссылки:
