Автоматазация unit-tests и отчётов с помощью Apex


Было дело, работал я на enterprise-проекте, в котором были сотни Apex классов с тысячами методов. Команда была распределенная из 7 SF разработчиков и проследить все изменения иногда было непросто. И иногда были случаи, что при релизе небольших изменений начинали падать совсем сторонние тестовые методы. Тогда и было решено смастерить что-нибудь для автотестирования. Хотелось реализовать функционал, который будет запускать все тесты на сандбоксе (или сандбоксах) автоматически, формировать отчет о результатах и, в случае недостаточного покрытия и/или падения некоторых тестов, будет информировать разработчиков с помощью отправки писем.

Для настройки автотестирования в Salesforce есть ряд служебных классов и объектов.

ApexTestQueueItem - объект для запуска тестового класса.
Все, что нужно - это создать экземпляр этого класса с одним заполненным полем:

  • ApexClassId - это ID запускаемого тестового класса. Получить его можно SOQL запросом из другого служебного объекта.

Поиск ApexClass
Поиск производился с помощью критерия **WHERE Name LIKE %Test%.

Запуск
Можно создать список ApexTestQueueItem объектов со всеми тестовыми классами и сделать insert.
После сохранения в БД, все тестовые классы добавляются в очередь и постепенно выполняются.

Проверка результатов
После этого можно зашедулить джобу, которая будет проверять результаты тестов. Информация о выполненных тестах хранятся в ApexTestResult объекте.

  • Название тестового класса хранится в поле : ApexClass.Name
  • Имя тестового метода в поле : MethodName
  • Результат в поле: Outcome.

Возможны следующие результаты:

  • Pass
  • Fail
  • CompileFail
  • Skip.

Нам интересны все результат, отличные от Pass. Для удобства можно создать кастомный объект и хранить там всю информацию о неуспешных тестах. Из этих записей можно легко сформировать удобочитаемый отчет например HTML-таблица, которая ночью
отправляется разработчикам.

Используя Tooling API, можно отправить запрос для получения информации о классах, недостаточно покрытых тестами (вся нужная информация хранится в ApexCodeCoverageAggregate объекте).

Каждую ночь отправлялось письмо с двумя таблицами, со списком всех классов, покрытых тестами менее, чем на 75%:
image

И списком всех упавших тестовых методов:

В общих чертах - всё.

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

3 Likes

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

Обязательно добавим в будущем)

Спасибо большое! Ждем с нетерпением.