Можно тестировать исключения . :-)

Как бы одно другому перпендикулярно.
Юнит-тесты, нужны для фиксации поведения класса/метода.
При этом не явно имея ввиду, что класс/метод является stateless.

Действительно нафига? :-)

Грубо говоря мы тестируем, например функцию, что должны получить, если подать не корректные значения.
Т.е. как мы реагируем, на не стандартную ситуацию.
И это поведение мы фиксируем в тесте.

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

А вот уже БЛ тестируется в интеграционных тестах.
Несколько другой инструмент.
Вот там как раз важно состояние, нужно подготавливать специально тестовые данные, поднимать хранилище данных с нужными данными и т.д.
Это более дорогое тестирование.

ИМХО юнит-тест это средство для разработчика, как например отладчик или "System.out.println".
Им можно пользоваться, можно не пользоваться.

Просто если есть юнит-тесты, то проще читать код.
Т.к. правда в коде и отчасти в тестах.
Всё остальное обычно врет. :-)

Вы просто не умеете их готовить (с) Не мой.

<:o)

Конкретно чему противоречит?

Есть юнит-тесты, которые тестируют stateless функциии/классы.
Есть модульные/интеграционные тесты, которые тестируют statefull функции/классы.

Если есть "состояние" это не юнит-тест.
Statefull тестировать дорого.
Либо нужно поднимать нужный контекст, либо обмазываться моками.
И то, и то "дорого", читай "не удобно".

Юнит-тест это инструмент разработки, а не тестирования.
В рамках методологии TDD.
И они (юнит-тесты) удобны/не удобны, в рамках умеет/не умеет программист этим инструментом пользоваться.

Еще раз юнит-тесты не про тестирование, юнит-тест про разработку.

P.S. Лично мне удобно, когда на проекте есть юнит-тесты, и они работают.
Т.к. они "правда", почти такая же, как код.
Что не скажешь о модульных/интеграционных тестах, особенно обмазанных моками.

И... Норм решение, чтобы не смотреть глазами 22.
В чем проблема?
Написали код, который за нас смотрит 22.

Я же говорю System.out,println :-)
Мне когда надоедает глаза ломать, пишу небольшой тестик, с assert-ами.
Даже не юнит.

Правда эти отладочные тесты "хрупкие" и их в прод нельзя выводит.
Но если приложить усилия, то можно из них сделать юнит- или модульный/интеграционный тест.
Т.к. понятно что проверяем.

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

Не совсем так.
unit-тесты в понимании методологии TDD, это тест, который не имеет контекста.
Но, например, в Spring Test контекст явно имеется, и для тестирования нужно его поднятие, с соответствующей настройкой контекста.
Это уже не unit-тест, т.к. то что мы тестируем явно имеет состояние, которое мы должны передать тесту. И оно может быть разным в зависимости от окружения. Например, в зависимости от переменных среды.
Мне удобнее называть их модульными/интеграцонными тестами. Т.к. они уже не unit, но ещё не полноценные интеграционные тесты.
ИМХО правильнее их называть все таки интеграционными тестами, т.к тестируется часть контекста спринга.

Они и про то, и про другое. Но эти тесты могут писаться и не по TDD и при этом оставаться тестами. Так что в первую очередь они все-таки про тестирование.

Не совсем.
Поведение программы тестируют интеграционные тесты.
Т.к. они воспроизводят некоторую последовательность действий.
И проверяют результат.

Unit-test определяет область определения и область значений функции/класса.
Можно написать 100% правильные unit-test со 100% покрытием кода, а на выходе получить не работающую программу.
Кроме того, unit-test имеет смысл писать ДО написания реализации, а не ПОСЛЕ.
Т.к. дизайн функций/классов может оказаться таким, что написать unit-test без глубокого рефракторинга не возможно.
Пример .