Было дело, работал я на 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%:
И списком всех упавших тестовых методов:
В общих чертах - всё.
Что касается преимуществ данного подхода - думаю, тут все очевидно: экономия времени и актуальная статистика по упавшим тестам и недостаточно покрытым классам. В условиях большой распределенной команды с сотнями тестовых классов и тысячами тестовых методов такая автоматизация очень упростит процесс поддержки старого кода и избавит от неприятных сюрпризов при деплое.