Вот наконец то дошел до момента, когда начал в Юнит тесте использользовать не одну-две-три тестовые записи, а много.
Тестирую тригер. В нем все селекты и дмл все циклов.
настроил Юнит тест на создание 50 тестовых записей (в самом юнит тесте, разумеется, все тестовые записи вставляются и апдатируются всей пачкой).
запускаю тест в Эклипсе - все ок.
настроил Юнит тест на создание 200 записей.
долго ждал ответа в Эклипсе, но все ок.
настроил Юнит тест на создание 300 записей.
Эклипс "завис" - черный экран в Эклипсе
есть ли какие то общие рекомендации о необходимом, желательном, оптимальном количестве тестовых записей в юнит-тесте?
спасибо
Добрый день.
Нверное какого-то числа - паноцеи нет, но могу посоветовать тригеры тестировать минимум с 201 записью, т.к SF автоматически разбивает все записи на батчи по 200 шт и если Вы делаете insert или другую DML
опреацию с 300 записями тригер запустится два раза- первый раз в нем будет 200 записей, второй - 100,
Может это прописная истина для меня но повторю еще,тест классов лучше создать отдельный класс с иницилизацией всех необходимых данны для орга.И вызывать каждый раз экземпляр этого класса пред началом конкретного теста по функционалу то есть initData должна делатся каждый раз перед тестом вашего фунционала как экземпляр класса.
ага, тригер работает с пачками по 200? тогда и беспокоится не о чем.
т.е. тригер в целом гоняет записи пачками как вот этот цикл:
loop, which iterates over the returned results in batches of 200 records:
for (List<Merchandise__c> ml : [SELECT Id,Name FROM Merchandise__c]){
// Do something.
}хотя постойте. гоняет он пачками, но ран контекст то один на все пачки... т.е. лимиты все равно хитнуть можно, но это должны быть тысячи записей.
спасибо
по поводу функционала создающего тестовые записи.
в примерах воркбуках есть data factories но это стат методы какого утилита класса, методы принимают кол-во требуемых записей и прочие детали и возвращают пачки записей (вставленные или нет). вызывай те стат методы, что тебе нужно и все.
А как создать тест дату через создание экземпляра какого-то класса? в чем разница?
Вот нашел такую книжку:
Effective Unit Testing: A guide for Java developers
http://www.amazon.com/dp/1935182579
но не знаю она нам в помощь, или в СФ все по-другому?
public class TestDataGenerate {
public void initDate() {
//some insert data
}
}
TestDataGenerate object = new TestDataGenerate();
object.InitDate();
Наверное хорошо использовать эти два метода в сочетании и т.д.
Подходы к написанию тестов я смотрю у всех разные.
Я для себя понял следующее - нужно разделять функциональное тестирование и стресс тестирование.
Изначально при написании тестов надо ориентироваться на жизненную ситуацию максимально точно воспроизводить действия пользователя. Тогда покрытие получится максимальным.
А уже отдельно производить стресс тестирование для участков кода, которые работают со списками объектов неопределенной длины - например триггеры, хотя могут быть и отдельные сервис функции.
Если функциональное тестирование нам необходимо как воздух, то стресс тестирование - обычно дело вкуса и я практически нигде не встречал такие тесты на реальных проектах.
Самое главное - не смешивать эти два типа тестов в один, иначе получится каша.
А по поводу количества объектов для стресс тестирования, правильно написал Дмитрий Черник про 200. Это магическое число в SF. Больше делать уже не обязательно.
С одной стороны Сергей прав. Исключение повторяющихся кусков кода. Тоже так делал одно время. Но основная проблема, которая возникла с использованием отдельной функции для инициализации, все созданные объекты оставались в scope данной функции, а очень часто в самих тестах нужно использовать созданный объекты. Для этого как-то необходимо их из функции вернуть, чтобы не кверить заново из базу. Можно конечно вернуть мапу созданных объектов, но как-то не хотелось городить огород. Поэтому старый добрый копипаст блока инициализации в каждом тестовом методе остался в арсенале.
