Привет.
Вот наткнулся на главной странице developer.salesforce.com (давно не заходил туда, даже дизайн не узнал)
на ссылку на интересную статью по теме Тестирования Apex
Там 2 видео туториала - так что можно особо не напрягать мозг чтением и просто послушать умных людей.
Ничего нового для ебя не увидел. 
Принципы везде одиаковые.
А может есть что добавить что там не увидел? 
Большая часть инфы в презентации уже известна (хотя эти знания и находились долгим методом проб и ошибок).
но много интересных деталей. как говорится "черт сидит в мелочах".
на слайде 23 используются:
- AwesomeTestLib чтоб получить юзера с нужным профайлом.
- UtilityClass устанавливает пермишин
- Аккаунт получают из TestFactory, как выясняется позже - вполне реальной...
просто прекрасно.
domain specific test helper учат помечать @isTest... полезно
как на слайде 34 он использует моск, я так и не понял, но можно позже разобраться..
а еще пишет
Mock anything you have in your service layer.
автор думает, что у нас есть service layer.
Оптимист...
также не понятно о чем это здесь (39):
Write your Visualforce controllers to use a single wrapper object.
Про Continuouis Integration - это очень важно, но я не понимаю как это физически сделать:
every code-change committed to your source repository triggers a full run of the tests. как можно для этого использовать Travis, Drone...
все что я могу - это заранить все тесты (после размещения новых классов) непосредтвенно через стандартный орговый UI или Дев Консоль. Как мне могут помочь эти тулсы? или они работают как плагины в IDE, которые помогают автоматически ранить все тесты и показывают результат?
есть вопросы. и это хорошо
Суть в том что считается плохой практикой использовать на странице домнные объекты, вместо них используются DTO и лучше и удобнее, чтобы это был 1 DTO а не 100500.
Суть в том, что весь твой код хранится в репозитории, ты делаешь изменение, коммитишь его, CI следит за изменениями, заливает их на сервер, запускает тесты.
Это отдельные приложения.
то есть Контроллер вообще не общается с sObjects (доменные объекты, БД) напрямую? он работает только с каким то промежуточным объектом? а что это дает?
ну как что: reusability. а потом, тестить контроллер можно вообще без создания даже тестовых данных, так получается? а если этот DTO вообще один на всех... очень интересно...
(удалено)
то есть Контроллер вообще не общается с sObjects (доменные объекты, БД) напрямую? он работает только с каким то промежуточным объектом? а что это дает?
ну как что: reusability. а потом, тестить контроллер можно вообще без создания даже тестовых данных, так получается? а если этот DTO вообще один на всех... очень интересно...
И не только это. В sObject нельзя добавиться свои методы, а рано или поздно это сделать будет надо и начнуться костыли.
похоже, вот это самое главное в истории про доменные объекты...
то есть какие-то "базовые", часто востребованные операции не выводятся в сервис классы (и сервис слой), и закладываются в "непосредственной" близости от sObject, в доменном объекте...
Domain Object != Data Transfer Object
Gres, дай простой пример:
вот это кастомный sObject,
вот это его доменный класс\объект,
а вот это, дети, Data Transfer Object, который использует дату из того самого sObject
http://stackoverflow.com/questions/6154311/what-is-the-difference-between-domain-objects-pocos-and-entities
Domain Object - объект, описывающий к-л бизнесс модель и определяющий ее поведение
Data Transfer Object - объект, предоставляющий обертку над к-л моделью, для удобства работы со связанными данными.
