сам понимаешь, доклад нужен

JPoker

не, пойнтер лучше

geek jokes

Доклад сделаю, можно будет посмотреть вместо написания тестов -> профит

всё лучше, чем тесты писать

В общем, посоветоваться со старейшинами Java 10, а то может только у нас в проектах никто не умеет, а на конфе без этого билет не продадут.

Кстати, тема для холивара. Наши юнит-тесты скорее не совсем юнит. Мы, например, тестируем целую инспекцию: задаём вход и сравниваем выход. Отдельные методы, работающие с PSI (в том числе публичные утилитные методы) обычно тестируются через какую-нибудь инспекцию, которая их использует. Пуристы скажут, что у нас всё плохо с юнит-тестированием. Я отвечу: а какую бизнес-ценность мы получим, если вложим большие ресурсы, чтобы сделать хорошо?

Отлично! @alexejv, доклад нужен

а писать через тесты не пробовали? разом же не будешь делать такой огромный функционал, что у вас надо подымать идею, чтобы асертнуть что парочка методов работает так как ожидаешь

> Мы, например, тестируем целую инспекцию: задаём вход и сравниваем выход.
Тесты есть разные. На метод, на класс-сервис, на часть, на всё систему. Если чего-то нет- это минус. Простые тесты сильно упрощают поиск проблемы.

Так это. Юнит — это элемент. Что назовёшь элементом — то юнитом и будет. Вот для тебя элемент — это инспекция )))

Один такой тест с подъёмом всего движка занимает секунд пять. Но если надо сто прогнать, то эти секунд пять один раз тратятся. Писать через тесты новую функциональность - это ортогональный вопрос. Можно писать точно такие же тесты, как у нас, вперёд кода. Если кому-то нравится - пожалуйста

Отлично, так и будем считать!

В том что я сейчас написал есть только небольшая доля шутки. И правда есть такое понятие как "объект тестирования" в тест-анализе. И именно он, по большму счёту, и является юнитом. Иногда внутри него можно найти ещё один или несоклько объектов для тестирования. Которые проще протестировать полностью отдельно, чем в составе большого блэкбокса. Оттуда и берётся пирамида тестов. Сложно и долго протестировать всё приложение через API — сложно воспроизвести все возможные ситуации через него.

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

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

а когда тесты не стоит писать?) за доклад наподобие «5 признаков что тест лучше не писать или писать но другой» я б сходил

Немного поправлю, Unit - это и есть модульное тестирование :)

модульные, компонентные, какая разница

ответ на вопрос «когда не надо писать именно такой тест?» менее актуальным не становится