Unit test: как лучше: один UT на весь проект или несколько UTов?

... (а сообщения удалять в форуме не возможно?)

[quote="Den Brown"]Всем привет?
в моих проектах мы обычно сдаем работу в Прод порционно, поэтому для каждой порции я пишу отдельный UT.

хотя сейчас осознал, что можно писать все в один класс, постоянно его дополняя, и перезаписывая при переносе в прод.

сейчас получил чужой проект, который пришел в текущий сендбокс одним Чендж сетом и с одним UT. но дальше в прод его нужно двигать по кускам. Плюс мне нужно покрыть тестами несколько новых классов...

вот сижу и думаю, дописать новые методы в старый большой UT или создать новый UT? 
! пока это писал - осознал - да как же я могу использовать этот большой старый UT при планирумом порционном переносе в прод, если в нем тестируются классы, которых в первых порциях переноса и в помине не будет?!

тогда вопрос: рубить его на куске навсегда, или писать все в один новый класс, постоянно его дополняя-расширяя новыми методами (с каждой порцией), и перезаписывая при переносе в прод? как организационно лучше?[/quote]
Мне просто интересно, а сам то ты как думаешь?

[quote="Gres"]Мне просто интересно, а сам то ты как думаешь?[/quote]

Я думаю, что идеально писать все в один новый класс, постоянно его дополняя-расширяя новыми методами (с каждой порцией), и перезаписывая при переносе в прод. Но может на таком пути есть какие-то неочевидные сходу подводные камни или ситуации, когда этот путь не сработает или окажется не таким уж и удобным?

[quote="Den Brown"]... (а сообщения удалять в форуме не возможно?)[/quote]
:D удалять нельзя!!! Можно редактировать.
[color=red]!!! Но лучше то что написал не изменять и тем более не удалять - признак хорошего тона[/color]
Возможно кто-то в этот момент пишет ответ на твое сообщение.
Если уж очень хочется изменить что написал, лучше поставь UPD: .... внизу.

[quote="Den Brown"]Я думаю, что идеально писать все в один новый класс, постоянно его дополняя-расширяя новыми методами[/quote]
Это плохой путь. Когда один работаешь еще можно как-то так работать, но если работает команда будет очень неудобно.
Каждому классу свой тест метод. Более того я против того, что некоторые "холявят" и пишут тесты для одного класса, которое автоматом покрывают другие. Я обычно в таких случаях экранирую вызов внешнего метода с помощью Test.isRunningTest. А внешний метод уже тестирует отдельный набор тестов для другого класса.
[b]Максимальная независимости кода[/b] - вот мое убеждение, тогда разработчикам будет проще и комманды могут меняться как угодно.

[quote="Dmitry Shnyrev"]Максимальная независимости кода - вот мое убеждение[/quote]

где-то краем уха слышал: написал класс - тут же включи в него тест-метод, так чтобы в самом классе был его UT. 
но что-то не уверен что так можно в апекс классом сделать: включить в него тест-метод

[quote="Den Brown"]
где-то краем уха слышал: написал класс - тут же включи в него тест-метод, так чтобы в самом классе был его UT. 
но что-то не уверен что так можно в апекс классом сделать: включить в него тест-метод[/quote]
Раньше можно было, потом это дело запретили (не помню какой релиз). Теперь только отдельные тест классы.
!И это еще раз подтверждает мое убеждение - независимость кода. В таком случае одновременно 2 разработчика могут работать над самим функционалом и тестами.

[quote="Dmitry Shnyrev"][quote="Den Brown"]
где-то краем уха слышал: написал класс - тут же включи в него тест-метод, так чтобы в самом классе был его UT. 
но что-то не уверен что так можно в апекс классом сделать: включить в него тест-метод[/quote]
Раньше можно было, потом это дело запретили (не помню какой релиз). Теперь только отдельные тест классы.
!И это еще раз подтверждает мое убеждение - независимость кода. В таком случае одновременно 2 разработчика могут работать над самим функционалом и тестами.[/quote]

Предпочитаю писать в пакете 1 тест класс. А если это простой код, то делю тесты на группы. Тест триггеров, тест вебсервисов и так далее.

[quote="Dmitry Shnyrev"]в таких случаях экранирую вызов внешнего метода с помощью Test.isRunningTest.[/quote]

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

[quote="Den Brown"][quote="Dmitry Shnyrev"]в таких случаях экранирую вызов внешнего метода с помощью Test.isRunningTest.[/quote]

а я думал, что это неплохо имитировать в тесте реальную цепочку событий, вызовов...[/quote]

Это вообще нужно делать всегда.

[quote="Den Brown"]а я думал, что это неплохо имитировать в тесте реальную цепочку событий, вызовов...[/quote]
Да, это удобно точки зрения удобности. Но тогда страдает гибкость разработки. Вот есть у тебя тест написанный для твоего класса который вызывает цепочку классов и свалился какой-то далекий левый класс, который в данные момент делает другой программист. Что ты будешь делать? Работа остановится, потому что тебе нужно будет дергать другого программиста чтобы он пофиксил свой баг. На это может уйти ОЧЕНЬ МНОГО времени, поверь моему опыту. И другой негативный момент, если ты покрываешь чужой код своими методами, то подписываешься под тем что теперь ты отвечаешь за чужой код, а другой программист в этом случае просто забьет болт на тестирование своего класса, потому ты уже покрыл их тестами. И подумай, кого поднимут в 2 часа ночи, когда при деплое свалятся твои тесты.
Да, с точки зрения структуры кода это может быть не очень соотвествует всяких принципам проектирования, но я уже не раз сталкивался с тем что мне приходится разгребать чужие косяки, и тесты это один из пунктов.

да действительно, цепочка событий может уткнутся в такие дебри, чужие дебри, за исправление которых тебе не платят или не дают время, то как вариант - экранировать ветку\вызов

[quote="Dmitry Shnyrev"]Да, с точки зрения структуры кода это может быть не очень соотвествует всяких принципам проектирования[/quote]
Я бы сказал совершенно не соответствует.

[quote="Gres"]Я бы сказал совершенно не соответствует.[/quote]
:) Пусть тогда это будет новый принцип проектирования - "модульный".
На один "модуль" один программист. Модули можно передавать, НО работать одновременно над одним модулем - ни в ком случае.

Модуль = страница (набор связанных страниц) + код который отвечает за их формирование + тесты.
Модули должны быть независимыми :) 
Также модуль - это отдельный scheduler или батч, web service.

на каждый класс (ну или скорей на каждый файл с классом/классами) свой тестовый класс.
а в нашем проекте в тестовых классах обычно по одному методу, который чаще всего называется myUnitTest.
у вас также?
я уже писал о том как был удивлен качеством кода в проекте и насчет unit тестов.

[quote="viktor_troeglazov"]а в нашем проекте в тестовых классах обычно по одному методу, который чаще всего называется myUnitTest. [/quote]
Сколько тестовых методов в классе это уже зависит от ситуации и личных предпочтений разработчика.
Например есть сложная страница + контроллер + service класс с бизнес логикой. Для всего этого создается 1 тестовый класс и в нем уже сколько надо методов под каждый use case.

[quote="Dmitry Shnyrev"][quote="viktor_troeglazov"]а в нашем проекте в тестовых классах обычно по одному методу, который чаще всего называется myUnitTest. [/quote]
Сколько тестовых методов в классе это уже зависит от ситуации и личных предпочтений разработчика.
Например есть сложная страница + контроллер + service класс с бизнес логикой. Для всего этого создается 1 тестовый класс и в нем уже сколько надо методов под каждый use case.[/quote]

в нашем проекте, вне зависимости от сложности кода обычно один метод в котором и "тестируется" вся функциональность.

я обычно делаю на каждый метод класса, один или несколько тестовых методов.

[quote="viktor_troeglazov"]я уже писал о том как был удивлен качеством кода в проекте и насчет unit тестов.[/quote]
Вот уже сами тесты могут быть написаны по разному (зависит от разработчика). Можно "покрывать" код тестами, а можно писать реальные "жизненные" тесты.
Народ помогите с терминологией, как правильно называются такого рода "жизненные" тесты. Unit test? И вообще, было бы круто, если кто-нибудь провел небольшой экскурс по основным понятиям из области тестирования.

[quote="viktor_troeglazov"]в нашем проекте, вне зависимости от сложности кода обычно один метод в котором и "тестируется" вся функциональность.[/quote]
Так можно делать, но есть вероятность влететь в лимиты если логика слишком сложная. У вас по ходу логика не сильно сложная, поэтому можно и так.
Также плюс отдельных методов в "чистоте базы" для метода. Зачем мучиться с очисткой данных от предыдущего отработанного кода, если можно просто сделать новый метод.

[quote="Dmitry Shnyrev"][quote="viktor_troeglazov"]в нашем проекте, вне зависимости от сложности кода обычно один метод в котором и "тестируется" вся функциональность.[/quote]
Так можно делать, но есть вероятность влететь в лимиты если логика слишком сложная. У вас по ходу логика не сильно сложная, поэтому можно и так.
Также плюс отдельных методов в "чистоте базы" для метода. Зачем мучиться с очисткой данных от предыдущего отработанного кода, если можно просто сделать новый метод.[/quote]

Вот тут ты не прав. Если использовать startTest и stopTest все нормально.

[quote="wilder"]Вот тут ты не прав. Если использовать startTest и stopTest все нормально.[/quote]
Боюсь что тут ты не прав :) startTest и stopTest позволяют увеличить лимиты только в 2 раза. Если в одном методе тестировать ВСЁ подряд, то и этих х2 лимитов не хватит.

Пока в этой теме собралось много серьезных людей спрошу вот что: нужно ли в тесте использовать try{ insert record;} catch конструкцию.

вижу в одном тесте try-catch-ем обернуты абсолютно все insertы.

но зачем оборачивать try-catch-ем инсерты подготовительных тестовых данных? нам ведь нужно чтобы они 100% вставились и никаких гвоз... кэтчей?

зачем оборачивать try-catch-ем "рабочие" инсерты, тестирующие тригер, ведь нам ведь тоже нужно чтобы все было чисто, просто 100% вставилось, без никаких кэтчей?

ну я понимаю что в try-catch берутся ДМЛ провоцирующие с тестовой целью исключения, например нужно зайти в тестируемом коде в его catch ветку. тогда понятно

простоя думаю что перехваченные catch-ем обломы в тесте не дадут ему упасть, но и работу тест никакую не сделает...


разъясните как правильнее

[quote="Den Brown"]вижу в одном тесте try-catch-ем обернуты абсолютно все insertы.[/quote]
По мне звучит как бред!!! Я даже не представляю зачем так нужно делать.
На то они и тесты, чтобы отлавливать исключительные ситуации! Т.е. никаких try-catch внутри.

UPD: хотя подумал тут немного. Да, для тестирования блоков кода, которые обрабатывают исключения, использование try-catch в самих тестах оправдано. Но для этого необходимо подготовить данные и вызвать метод внутки try-catch, который по логике должен свалиться с ошибкой, но при этом что-то сделать. Но это точно не будет похоже на оборачивание всех DML операций в try-catch. На моей практике не встречались столько сложные обработчики ошибок, чтобы их нужно было тестировать. Поэтому я просто пренебрегаю этими кусками логики. 

[quote="Dmitry Shnyrev"]Народ помогите с терминологией, как правильно называются такого рода "жизненные" тесты. Unit test? И вообще, было бы круто, если кто-нибудь провел небольшой экскурс по основным понятиям из области тестирования.[/quote]
Я использую 3 вида тестов:
- юнит
- функциональные
- интеграционные

[quote="Gres"]Я использую 3 вида тестов: 
- юнит 
- функциональные 
- интеграционные[/quote]

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

[quote="Dmitry Shnyrev"][quote="wilder"]Вот тут ты не прав. Если использовать startTest и stopTest все нормально.[/quote]
Боюсь что тут ты не прав :) startTest и stopTest позволяют увеличить лимиты только в 2 раза. Если в одном методе тестировать ВСЁ подряд, то и этих х2 лимитов не хватит.[/quote]

О нет, я прав:) у меня 1 тестовый класс в котором 15 тестовых методов и все чудненько теститься. Кода около миллиона символов.

[quote="wilder"][quote="Dmitry Shnyrev"][quote="wilder"]Вот тут ты не прав. Если использовать startTest и stopTest все нормально.[/quote]
Боюсь что тут ты не прав :) startTest и stopTest позволяют увеличить лимиты только в 2 раза. Если в одном методе тестировать ВСЁ подряд, то и этих х2 лимитов не хватит.[/quote]

О нет, я прав:) у меня 1 тестовый класс в котором 15 тестовых методов и все чудненько теститься. Кода около миллиона символов.[/quote]
Подожди, мы про ОДНИ тестовый КЛАСС говорим или ОДИН тестовый МЕТОД в тестовом классе?
Да, в один класс можно запихнуть хоть 1000 методов (наверное, не пробовал).
А все началось с того что
[quote="viktor_troeglazov"]в нашем проекте, вне зависимости от сложности кода [color=blue]обычно один метод в котором и "тестируется" вся функциональность.[/color][/quote]
Виктор сказал про один МЕТОД. Один метод - один контекст, один набор лимитов. Вернее 2 набора лимитов: до test.startTest и после. Т.е. если я в один МЕТОД запихну 201 SOQL запрос, то у меня никакой метод не отработает, а просто свалится по лимитам.
Так что я понимаю, что мы говорим о разном :) 

[quote="wilder"]у меня 1 тестовый класс в котором 15 тестовых методов и все чудненько теститься.[/quote]
А как вы работаете если надо одновременно двум разработчикам исправить тесты в этом тестовом классе?
Я так полагаю что изменения делаются отдельно, а потом мержатся с помощью системы контроля версий?

[quote="Gres"]Я использую 3 вида тестов: 
- юнит 
- функциональные 
- интеграционные[/quote]
А можешь хотя бы по одному предложению рассказать в чем их отличие, желательно в проекции на Salesforce.

[quote="Dmitry Shnyrev"][quote="wilder"]у меня 1 тестовый класс в котором 15 тестовых методов и все чудненько теститься.[/quote]
А как вы работаете если надо одновременно двум разработчикам исправить тесты в этом тестовом классе?
Я так полагаю что изменения делаются отдельно, а потом мержатся с помощью системы контроля версий?[/quote]

Так точно. Изначально пишется отдельный класс для всех новых тестов, а потом после отладки уже включается в основной класс

[quote="wilder"]Так точно. Изначально пишется отдельный класс для всех новых тестов, а потом после отладки уже включается в основной класс[/quote]
Ну в принципе страдает скорость в пользу удобства архитектуры.
Я так понимаю что "быстрые изменения" у вас не в почете. Например поменял кто-то логику, сломались тесты в главном тестовом классе, как вы это дело разруливаете?
Хотя в принципе при нормальной организации труда, правильной работе с системой контроля версий, раздельной работой разработчиков на своих оргах и сливе кода через репозиторий на главный орг (сандбокс) (эх, скучаю по этим временам) все должно быть красиво :) 

У меня последний года два просто проекты - вот у нас есть сандбокс (где работает куча программистов) - работай. По началу дергался со своими дев оргами, а потом забил. Работаю напряму с сандбоксом, свой код складываю в локальный git (чтобы не проехххть). Сделал -> показал -> changeSet -> Prod :) 

Если я правильно понимаю, то
- юнит тести
    [i]тестируется какаето часть(юнит, модуль) программы. В сф я представляю это как тестирование конкретного метода,     тупо проверяем что наш метод справляется со своей задачей. Хотя, как по мне, то юнит тестирование которое в сф, сложно назвать юнит, здесь нет возможности создать mock, и иногда нам чтобы потестить какой то метод, нужно еще несколько других вызвать.[/i]

- функциональные 
    [i]проверяется, делает ли код то что нам нужно, точнее проверяется именно то, для чего предназначен кусок кода.  
[/i]
- интеграционные
    [i]проверяется не ли каких то конфликтов, при взаимодействии нескольких компонентов.
[/i]

Я еще пищу нагрузочные тесты, например при тестировании триггера, постоянно проверяю что он не вылетит за лимиты при обработке 200 записей.

P.S. я когда проходил интернатуру, нам давали задание, потестировать карандаш(ну вообщем [url=http://habrahabr.ru/post/193902/]вот интересная стаття об этом[/url])

Мне вот понравилась эта картинка:
[img]http://habrastorage.org/storage3/be8/09d/fa0/be809dfa055ab484acad7a8e632fd46d.jpg[/img]

[quote="Alex Tsitsura"]Если я правильно понимаю, то
- юнит тести
    [i]тестируется какаето часть(юнит, модуль) программы. В сф я представляю это как тестирование конкретного метода,     тупо проверяем что наш метод справляется со своей задачей. Хотя, как по мне, то юнит тестирование которое в сф, сложно назвать юнит, здесь нет возможности создать mock, и иногда нам чтобы потестить какой то метод, нужно еще несколько других вызвать.[/i]
[/quote]
насчет mock можно так писать: Test.setMock(WebServiceMock.class, new Test_OneSService());

Test.setMock ето конешно хорошо, но, ето не совсем mock. Ми его можем применять только к webservise & httpcallot. А вот полноцений mock позволяет создать заглушку практически для всего что угодно, и таким образом можно действительно написать чистие юнит тести.

Alex Tsitsura все правильно написал.
Нагрузочные тесты тоже очень хорошая вещь.
В последних проектах постоянно использую Service Locator, чтобы можно было писать стабы и моки.

[quote="Alex Tsitsura"]Test.setMock ето конешно хорошо, но, ето не совсем mock. Ми его можем применять только к webservise & httpcallot. А вот полноцений mock позволяет создать заглушку практически для всего что угодно, и таким образом можно действительно написать чистие юнит тести.[/quote]
Используй dependency injection и будет тебе счастье

Не знал в какой теме написать.
Но в общем у меня такая проблема.
Почему-то выполнение тестов в Developer Console выдает какие-то странные результаты:
1) Покрытие для некоторыех классов выглядит как будто я их не изменял (т.е. количество строк не соответствует действительности + кривое отображание покрытия)
2) Общий результат не верен (из п.1), т.к. считает по (общее количество покрытых строк)/(общее кол-во строк).

Что можно сделать для нормального отображения? Очистка (Test -> Clear Test Data) не помогает.

Ну и заодно, как обходить данную ситуацию:
Разработка нескольких проектов идёт на одном инстансе. В каких-то проектах появляются обязательные поля для объектов, соответственно надо заполнить это поле в тесте.
Каким образом потом лить на инстанс, на котором этих полей нет вообще?)
Или можно считать бэд практис менять стандартные объекты и добавлять requirement fields?

[quote="RasMisha"]Ну и заодно, как обходить данную ситуацию:
Разработка нескольких проектов идёт на одном инстансе. В каких-то проектах появляются обязательные поля для объектов, соответственно надо заполнить это поле в тесте.
Каким образом потом лить на инстанс, на котором этих полей нет вообще?)
Или можно считать бэд практис менять стандартные объекты и добавлять requirement fields? [/quote]
1. Рефлексия
2. Предполагается, что разработка ведется на инстансе с таким же набором метаданных, как и на проде

1. Костыль (как заполнять, при условии, что не знаешь какие должны быть значения + никто не отменяет еще какие-нибудь Validation Rules)
2. Не предполагается, когда несколько проектов делаются на одном инстансе (особенно если для разных людей/компаний).

Опять же рассмотрим ситуацию когда какое-то приложение на инстансе, куда ты льешь своё приложение, уже имеет подобные requirement fields, validation rules у стандартных объектов.

ps забавно общаться на форуме, когда ты сидишь рядом) может еще у кого какие мысли?

[quote="RasMisha"]2. Не предполагается, когда несколько проектов делаются на одном инстансе (особенно если для разных людей/компаний).[/quote]
Значит ССЗБ

[quote="RasMisha"]Опять же рассмотрим ситуацию когда какое-то приложение на инстансе, куда ты льешь своё приложение, уже имеет подобные requirement fields, validation rules у стандартных объектов.[/quote]
Опять же ССЗБ, если не используешь копию метадаты

Иногда просто НЕТ доступа ко всей метадате прод.орга.
Скорее уже РПЗБ (рабочий процесс и так далее по тексту, гг).

[quote="RasMisha"]Или можно считать бэд практис менять стандартные объекты и добавлять requirement fields?[/quote]
Я именно так и считаю - бэд практис. Вообще я ярый противник использования стандартных объектов и тем более навешивания на них всяких кастомных обязательных полей и проверок если дело касается разработки пакетов. Но пока мало кто меня поддерживает, потому что не догадывается к каким это может привести проблемам. Пока с теми проектами что я сталкивался архитекторы считают что надо по максимуму использовать стандартные объекты. Мы кстати уже эту тему обсуждали - https://salesforce-developer.ru/forum/topic-v-chem-preimuschestvo-ispolzovaniya-standartnyh-obektov

[quote="RasMisha"]Что можно сделать для нормального отображения? Очистка (Test -> Clear Test Data) не помогает.[/quote]
Странное поведение. Мне обычно помогает.
Была раньше такая проблема, когда убрали покрытие в Developer Console. Я тогда написал небольшой скрипт на puthon (успешно его потерял :( ) который тянул данные о покрытии через Tooling API.
Может тоже в этом направлении глянуть. 
Других решений не вижу.

[quote="RasMisha"]Ну и заодно, как обходить данную ситуацию: 
Разработка нескольких проектов идёт на одном инстансе. В каких-то проектах появляются обязательные поля для объектов, соответственно надо заполнить это поле в тесте. 
Каким образом потом лить на инстанс, на котором этих полей нет вообще?) [/quote]
Ну я бы со своей колокольни мог посоветовать только одно - разнести все по разным оргам и лушче проработать тему синхронизации данных оргов. Как мне показывает практика - даже для одного проекта мало одного орга, чего уж говорить про несколько на одном. К тому же созданием дев оргов не такая уж сложная задача :) .
Я думаю если объединитесь с Wilder и Gres, то найдете правильное решение по синхронизации :) они постоянно в этой теме варятся.

[quote="RasMisha"]ps забавно общаться на форуме, когда ты сидишь рядом) может еще у кого какие мысли?[/quote]
И забавно и полезно для истории. Одно дело просто обсудить и забыть, а так останется еще в чьих-то головах, например моей :D .  А может придет время и придет Salesforce на русскую землю, убъёт местное чудовище под названием 1с и тогда слова ваши, высеченные в камне, будут читать не одно поколение salesforce разработчиков :D 

Покрытие нормально показывается в MavensMate.
Но мне хочется и в DC нормальное покрытие.
Само отображение регулируется в настройках Apex Tests