salesporce hat.jpg

Автоматизируем тестирование Salesforce. Вводная часть

26 сентября 2019

Мы запускаем цикл материалов о тестировании. В качестве авторов приглашаем специалистов из iTechArt. Руководитель отдела тестирования Дмитрий Рак рассказывает об автоматизации тестирования Salesforce. Личный опыт, пасхалки, лайфхаки и немного юмора в первой статье.

«Когда-то Salesforce можно было назвать CRM-системой на основании SaaS-модели»

Некоторое время назад ко мне в команду пришел запрос на автоматизацию тестирования проекта, построенного на платформе Salesforce. Я решил расписать задачи/идеи и проблемы с которыми мы сталкивались на проекте. Так как объем полученных знаний и опыта довольно велик, статью придется разбить на несколько частей. Первая часть, скорее, вводная и дающая общее представление о том, из чего состоит автоматизация в Salesforce. Итак, скепсис по отношению к такой задаче сразу же был максимальным из-за следующих стереотипов в моей голове:

Salesforce − это уже готовый продукт, который просто кастомизируется под ваш WorkFlow, зачем там тестирование?

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

И вот спустя 9 месяцев на проекте я делюсь своими мыслями, идеями и болью насчет возможности и подходов к автоматизации тестирования Salesforce.

Когда-то Salesforce можно было назвать CRM-системой на основании SaaS-модели. С ходом времени платформа поглощала разного рода организации, начала предоставлять возможность разработки приложений на своей же базе используя модель PaaS. В последнее время платформа сильно углубилась в аналитику, BI и маркетинг, в основном, за счет поглощения таких компаний, как Buddy Media и Tableau (куплена, кстати, в этом году примерно за 16 млрд. долларов).

На данный момент у Salesforce кроме настройки тех самых WorkFlow есть свой язык программирования, называемый Apex. Язык строго типизированный, объектно-ориентированный, синтаксис сильно напоминает Java. Несколько крутых для автоматизаторов знаний об Apex и Salesforce приведу ниже:

  • Синтаксис понятный, построен в сущности на триггерах, описании объектов и запросах к базам данных;
  • На Apex можно писать Unit-тесты. Salesforce обязывает разработчиков иметь покрытие кода тестами на уровне не ниже 75%. Иначе билд не будет успешным;
  • JS и верстка все еще нужны, но большинство страниц могут быть собраны из предоставляемого самим Salesforce конструктора (т.е. UI тестировать практически не нужно, так как одно поле не отличается от второго, имеющего просто другое название);
  • Доступ к базе данных через JDBC не получить. Зато к каждому объекту в системе автоматически генерируется REST API с полным CRUD.

Подходы к тестированию

Итак, у нас есть покрытие кода по дефолту >75%. У нас есть UI, которые в большинстве случаев пишется не разработчиками, а составлен из стандартных компонентов. Тестирование необходимо, по сути, на уровне бизнес-логики и взаимодействий между разными компонентами UI и вызова триггеров. По сути, для грамотного построения пирамиды тестирования нам осталось добавить ~20-25% тестов на REST API и еще ~5-10% на UI. UI для практического любого объекта в Salesforce состоит из следующих страниц.

В PageObjects, соответственно, описываются некоторые формы. В Salesforce разработчики могут создавать формы тремя способами, локаторы для полей, находящихся на них, соответственно, будут отличаться:

Далее разберемся по типам полей, которые могут присутствовать на этих формах. Если разбирать наиболее часто используемые, то это:

  • Input (VisualforceInput.java, SalesforceInput.java, LightningInput.java);
  • TextArea (VisualforceTextArea.java, SalesforceTextArea.java, LightningTextArea.java);
  • Select (VisualforceSelect.java, SalesforceSelect.java, LightningSelect.java);
  • MultiSelect (VisualforceMultiSelect.java, SalesforceMultiSelect.java, LightningMultiSelect.java).

В теории локаторы могут иметь внутри себя логику "ИЛИ" и тогда можно уйти от 3 классов для разных технологий.

В итоге каждый из 3 PageObjects, перечисленных выше, должен состоять из полей, соответствующих типов, которые отличаются только названием. Вся внутренняя кухня по поиску локатору находится внутри обертки под элемент. Имея такую базу из массы страниц и полей, под них можно собирать любые тесты на CRUD-операции внутри Salesforce. Из таких CRUD-операций и состоит наш Build Verification Test. Для проверки более сложной логики подготавливается масса исходных условий, все они по-максимуму готовятся через REST API. О том, как взаимодействовать с Salesforce REST API, поговорим в другой статье, а пока обсудим с какими проблемами в итоге пришлось столкнуться во время автоматизации:

  • Salesforce позволяет пользователям работать в разных вкладках внутри приложения. В итоге локаторы − это сплошные XPATH, где в начале идет префикс для текущей активной вкладки, потом только сам локатор;
  • Salesforce позволяет логиниться без двухфакторной аутентификации только с "Trusted IPs". Как варианты обхода: отключить такую аутентификацию, получать сессионные куки и подставлять их в драйвер, добавить все IP как доверенные в Git-репозиторий, чтобы настройки не сбивались после каждого деплоя приложения. Либо использовать плагин для Chrome, которые за пару секунд добавит ручками все IP в конфиги вашей организации: https://chrome.google.com/webstore/detail/whitelist-all-ips-for-sal/nnlnikmkkbpgioojghgojoejgcheilic
  • Зоопарк Roles/Profiles и Permission Sets внутри организации, а также невозможность создавать пользователей налету через, допустим, REST API приводит к довольно монотонной подготовке тестовых данных после копирования данных с продакшн-сервера на сервер для автотестов (если, конечно, вам нужны prod-like данные).

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

337
Стань частью нашей команды