Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Примерно месяц назад я получил сообщение от контакта в LinkedIn со ссылкой на статью Forbes и вопросом:

“Как вы думаете, codeless - хорошая штука, или нет?”

Я отправил подробный рассказ о своем мнении про статью и ‘codeless’ (позже вы поймете, почему здесь и далее я пользуюсь кавычками) как феномене автоматизации. По какой-то причине мне пока не ответили, и, дабы мои усилия не пропали зря, я превратил свой ответ в статью, которую вы сейчас читаете.

Итак, считаю я codeless хорошей штукой или нет?

Ответ - и да, и нет. Но все же больше нет, чем да. Сейчас поясню.

У меня нет никаких проблем с инструментами, предоставляющими дополнительный уровень абстракции над утверждениями и, в сухом остатке, битами и байтами, из которых состоят тесты. Это и делают low-code инструменты: дают уровень абстракции. В моем текущем проекте мы активно пользуемся таким инструментом, и зачастую успешно.

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

• Снова код.  REST Assured, к примеру, дает уровень абстракции поверх библиотек Java HTTP, упрощая создание тестов уровня API на Java.
• Это может быть иная текстовая форма.  Robot Framework, к примеру, позволяет инженерам писать тесты в табличной форме, используя ключевые слова.
• Это может быть графический интерфейс пользователя. Postman, к примеру, предоставляет графический интерфейс, позволяющий писать тесты при помощи широкого спектра готовых блоков, которые можно контролировать через GUI Postman.

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

Самая большая проблема, по моему мнению, тут в том, что эти уровни абстракции привносят потерю гибкости. Так как вы не контролируете код под капотом, вы зачастую становитесь запертыми среди того, что предоставляют уровни абстракции ваших библиотек и инструментов. Иногда это не проблема, иногда это вас тормозит - или сразу же, или в будущем. Как всегда, “зависит от”.

В целом у меня нет проблем с уровнями абстракции, как и с low-code инструментами автоматизации вроде Robot Framework или Postman. Они зачастую приносят пользу, если их аудитория понимает, что это уровни абстракции, а под ними все еще находится код.

И тут-то и начинаются мои проблемы с ‘codeless’-феноменом.

Конечно, ‘codeless’ - это отличный маркетинговый термин, но он обещает то, чего не может сделать. Неважно, пользуетесь вы low-code инструментом или нет - вы все еще пишете ПО, просто с иным синтаксисом, предоставленным уровнем абстракции.

Это означает, что даже если вы пишете что-то непохожее на Java, Python, C# или любой другой любимый вами язык, вам все еще нужен навык разработки (способность моделировать, создавать дополнительные уровни абстракции, готовые блоки для повторного использования, и т. п.)

Если вы этого не понимаете и не внедряете хорошие принципы программирования систематически, то в какой-то момент вы загоните себя в угол, окружив себя кучей трудного для поддержки автоматизированного мусора - неважно, кода или low-code.

Люди недостаточно понимают это, и отрывок из статьи, на которую я сослался в самом начале, подтверждает мою мысль:

Идея в том, чтобы кто угодно в компании, от инженеров и менеджеров продукта до маркетинга, финансов, юристов, продажников - мог быстро и легко создавать автоматизированные тесты, не создавая ни одной строки кода и не имея никакого опыта в программировании или автоматизации.

Это просто так не работает. Если вы создаете ПО, неважно, приложение или автоматизированные сценарии - вы разработчик. Вам нужен навык разработки. Синтаксис low-code инструментов может отличаться, но базовые навыки (объектно-ориентированное мышление, способность передавать процессы в код, и т. д.) остаются прежними.

Резюмируя, я не противник low-code инструментов, но надо всегда держать в уме, что вне зависимости от синтаксиса вы создаете ПО. Это требует навыков и опыта, того, что приходит на практике. Да, кто угодно может этим заняться - после того, как затратит время на наработку навыков и опыта - но я сомневаюсь, что это то, что подразумевают маркетологи этих ‘codeless’-инструментов.

Заключение: еще одна проблема тут в том, что множество low-code инструментов (я специально избегаю термина ‘codeless’, такой штуки просто не существует) зачастую работают только в full stack-режиме, действуя на уровне графического интерфейса приложения. Это значит, что созданные в этих инструментах скрипты зачастую можно создать только после того, как разработка приложения завершена. Зачастую это слишком поздно.

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

Обсудить в форуме