Владимир Ситников - assertTrue, как много в этом слове...

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . Многие слышали про arrange-act-assert. И про single assert слышали. В этих подходах буква «Л» обозначает лёгкость поддержки тестов, а «П» - понятность их вывода.
Тест может падать по разным причинам (на CI другое окружение, больше выполняющихся тестов, больше нагрузка и проч.), но вопрос «почему же упало» остаётся.
В докладе мы рассмотрим, как современные инструменты (JUnit 4/5, Spok, Power Assert, Truth) позволяют писать тесты так, чтобы их падение было проще анализировать, а сами тесты было проще поддерживать.

[@romantsyupryk3009]

Большое вам спасибо за это доклад.

[@antongromov8093]

Подскажите, пожалуйста, какой инструмент используется для показа презентации? Довольно-таки приятная анимация)

[@ZhekaKozlov]

Не знаю, что использовал Владимир, но MS PowerPoint так умеет. Там много всяких видов анимаций, и довольно просто делаются, если немного потренироваться.

[@VladimirSitnikov]

@@ZhekaKozlov , в PowerPoint движение текста гораздо сложнее делать. Несколько лучше дела обстоят в Keynote (там действительно лучше анимации), но для доклада, где нет схем, а в основном код от Keynote тоже негусто пользы

[@igorlu]

Прям отлично. Полностью согласен, что тест должен не только падать но и внятно "объяснить" почему. Способ писать в консоли код который пройдет тест 41:00 использую в десериализаторах, когда он получает другую схему и не может десериализировать объект, то в лог кроме всего, я пишу сгенерированный класс по новой схеме, с нужными полями и типами, очень сокращает время на поиск, чего же там не хватает или если это новый объект, то просто копирую в него сгенерированное.

[@MrZemzer]

Отличный доклад! Но мне кажется, assertTrue выглядит как то не консистентно, тем более когда есть достаточно других вариантов. AssertJ имеет кучу разных проверок, включая isSame(==), isEquals(equals), usingRecursiveComparator.isEquals(field by field) и все это описано в доке

[@VladimirSitnikov]

Спасибо! "assertTrue выглядит как то не консистентно". Вообще говоря, если нужно проверить метод, который возвращает boolean, то assertTrue нормально, и едва ли оно хуже какого-нибудь isEquals(true). Например: assertTrue("Connection.isValid should return true unless the connection is closed", con.isValid(4 /*seconds*/)). Но такие методы встречаются. В среднем я считаю, что от assertTrue больше вреда, т.к. этим методом часто пользуются неправильно. Этот доклад я делал из-за того, что слишком часто встречал неуместное использование assertTrue/assertEquals. Касательно usingRecursiveComparator тоже не всё гладко: AssertJ сравнивает, но оно не отвечает на вопрос "почему" мы ожидали того или иного значения. Там всё равно нужно указывать (либо в названии метода-класса, либо в сообщении) то, какие данные подавали на вход, и почему именно ожидали увидеть те или иные результаты. AssertJ лишь помогает сравнивать (это важно), но оно не помогает для code review. Основной вопрос когда смотришь на код -- "почему ожидается именно такое значение?" И на него assert методы не отвечают.

[@MrZemzer]

@@VladimirSitnikov спасибо за ответ! Согласен на счёт того, что assertTrue часто используют неправильно. На счёт ответа на вопрос "почему" - не уверен, что ассерт вообще должен отвечать на такой вопрос. Ассерт проверят "что", а на "почему" должна отвечать либо простая структура теста, либо нейминг. Но это лично мое мнение

[@VladimirSitnikov]

​@@MrZemzer Тут без примеров обсуждать тяжело. Можете показать пример, где assertЧтоНибудь(a, b), и без сообщения? И на нём разберём почему сообщение хорошо бы добавить. Случаи, когда сообщение не нужно бывают крайне редко. Прямо очень редко. Возможно, частотность тех случаев совпадает с частотой уместного использования assertTrue :)

[@MrZemzer]

@@VladimirSitnikov да, согласен. Можем продолжить обсуждение в каком то мессенджере? Комментарии Ютуба не самое удобное и доступное для меня место :)

[@pavelpetrashov2975]

На такие тесты надо тесты писать

[@semremal]

Все хорошо, но экономить наносекунды в тестах - так себе идея.