Pull to refresh

Comments 11

Вот вы говорите "как правильно", но почему именно так — не говорите. Это секрет или вы не знаете?


Гляньте на мои аргументы что ли: https://habr.com/ru/post/353080/

У вас там так много аргументов, что я не знаю, какой вы имеете в виду. Я, кажется, с основными согласен. Неявные ассерты плохо, один ассерт на тест — согласен, но нерелизуемо пока, про given /when не согласен.

assertNotNull(order)
assertNotNull(order.getCustomer())
assertNotNull(order.getCustomer().getName())

Ну вот что даёт эта копипаста? И как оно соотновится с вашим же предложением "проверять нужно именно это, а не assertNotNull"?

В данном случае копипаста показывает, что именно упало — и что мы на это рассчитывали,. Потому что если выпадет нульпойнтер до ассерта, то неясно какой именно в Order или order.getCustomer, и неясно, пропустили мы его случайно или осознанно.


Пойнт про valid order состоит в том, что надо проверять валидность ордера, а не просто нульпойнтер, коль скоро мы это задекларировали. Как именно валидность определена — это зависит от имплементации, главное не пренебрегать ассертами. Многие в погоне за покрытием ставят минимальный ассерт и бегут дальше.

неясно какой именно в Order или order.getCustomer

Всё ясно:



неясно, пропустили мы его случайно или осознанно

Да какая разница? Есть ошибка — её надо исправить.

В джаве будет просто нульпойнтер на этой строчке. Разница в том, что намерения пишущего должны быть ясны. Может, там не должно быть в принципе нулевого кастомера. Может быть, нужно фиксить не код, а фабрику.

В джаве будет просто нульпойнтер на этой строчке.

Значит в java следует везде избегать цепочек вызовов, иначе не понятно, где именно возникла ошибка. Тесты тут ни при чём.


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

Они и так предельно ясны — нулевого кастомера быть не должно.

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

Так ему и не надо проверять все нули в любом случае.

Тут я согласен с vintage единственная проблема — менее читаемое сообщение об ошибке. Будет просто NPE, но это общая проблема для всего кода на Java.


А еще есть Kotlin, который заставить в синтаксисе выразить отношение к Null в конкретном месте.

есть и котлин и ломбок, и статический анализ, но они касаются имплементации, а тут чисто описание сценария, которое должно быть отделено от имплементации. Мой пример — невнятный в данном случае — был против недостаточного (когда тестируют только конечные проперти) и избыточного (когда тестируют все приехавшее из метода). Я подумаю, как расписать полнее.
Sign up to leave a comment.

Articles