Читабельный тест

[Gluttton]

Юнит. Что это такое?

Для меня это всегда функция (или функция-член).
Кстати здесь:

Связь результата со входными параметрами и есть суть функции.

И вы тоже проговорились, что юнит — это функция. Или описались.

Явность юнита

И тогда Subject — это имя функции.

Предикативность теста

Именно поэтому в качестве сказуемого предиката строго настрого запрещены такие паразитные слова как «correctly», «good», «fine», «well»...

Хм… Я добавляю суффиксы Success, Fail, Throw, которые отражают ожидаемый результат. Т.е. иногда я пишу тесты на положительный результат, а иногда и на отрицательный. Для арифметических операций смысла в этом мало, но при написании тестов на нетривиальную бизнес-логику или на парсер (мой случай) это может быть полезно.

Состояние и юниты

Не осилил.
Когда мне нужно выполнить нечто подобное, то я делаю вот так.

Не говорю, что я делаю правильно, даже скорее хочу услышать критику.

Статья интересная, спасибо.

[omnisens]

Я и не отрицаю, что в частном случае функция может служить примером юнита. Я рассматриваю этот случай в секции «Пустое окружение». Если вдуматься в этот пример, можно заметить, что пустое окружение в моей терминологии эквивалентно чистоте функции в функциональных языках. Т.е. вся семантика этого юнита заключена в проецировании входных данных на выходные. С недавнего времени я сам очень сильно полюбил чистые функции (особенно, после изучения Haskell), и да — немаловажную роль тут играет тестируемость таких чистых функций. Однако, не всегда код можно написать в виде чистых функций. Тот же Haskell имеет понятие IO, которое подразумевает некое состояние. Именно из-за состояния приходится рассматривать юнит как нечто общее нежели простая функция. Если вернуться к парадигме command query separation, то можно заметить, что эти разделенные команды и запросы, хоть и являются функциями, юнитами их назвать нельзя, так как из-за однонаправленности данных (в команды они входят, из запросов — выходят), проверить семантику юнита не представляется возможным; информация оседает в промежуточном хранилище, которое и является состоянием объекта. Именно из-за этого состояния нам приходится расширять понятие юнита до пары функций и общего их состояния. У меня в статье это пример std::list-а и несамодостаточности его однонаправленного (команды) метода remove.

[nhekfqn]

Спасибо за статью! В этой профессии станет намного приятней и интересней работать, если больше программистов осознают необходимость писать читабельный и понятный не только автору код. Для этого нужно больше таких статей, объясняющих что такое читабельный код и как этого добиться. К сожалению пока новый (для меня) проект — по умолчанию авгиевы конюшни и несколько недель чтобы разобраться во всех шарадах и переписать хотя бы самые ужасные участки.

[omnisens]

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

[Nashev]

Это ж не habr.com/ru/post/187568 было? Выкладывалось?

[dmitriy_t]

Явность тестовых данных
Правило: Все тестовые данные (как входные, так и выходные), ровно как и данные читаемые из окружения или пишущиеся в окружение, должны присутствовать в теле теста.

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

[omnisens]

Если входные данные огромные (или даже просто немаленькие), то данный тест — это уже не юнит тест. Это может называться интеграционным тестом, регрессионным тестом или даже автотестом. Как правило, юнит тесты, по крайней мере те, которые написаны в стиле TDD, проверяют маленький кусок функциональности, на который достаточно повлиять парой-тройкой (если вспомнить закон триангуляции) высокогранулированных значений. Большие объемы данных чаще всего пригождаются чтобы прогнать систему или некоторую ее подсистему через серию тест-кейзов для нагрузочного тестирования или просто как некоторые чекпойнты. А это уже что-то более высокомасштабное.

[dmitriy_t]

Извиняюсь — огромный ошибочно написал (он огромный визуально по сравнению с численной константой, надо было уточнить что я имел в виду). Я конечно имел в виду небольшой 10-20-ти строчный текстовый дамп не более 80 символов в строку. Так вот я не уверен что копипастить такой кусок в несколько тестов это правильно.

[omnisens]

Копипастить данные — неправильно, с этим соглашусь. А вот к необходимости использовать одни и те же данные в разных тестах отнесусь скептически. Если одни и те же данные подаются на вход разным тестам, то возможен один из следующих вариантов:

1. Данные используются тестами неполностью, и каждый выгребает из этого множества то, что интересно именно ему. В данном случае выразительность теста понижается, потому что непонятно, какие именно данные влияют на проверяемое поведение.
2. Данные нужны обоим тестам полностью. В данном случае налицо дублирование ответственности между разными юнитами, либо, если проверяются разные аспекты одного и того же юнита, то имеет место быть слишком сложная конфигурация юнита для получения простого функционала. Это говорит о низком реюзабилити (повторной используемости — так оно переводится?) юнита.

Все зависит от цели, с которой пишется юнит тест. Если цель — иметь защиту от регрессии и возможность спокойно рефакторить, то уж лучше иметь хоть какие-то тестовые данные, и если возникает необходимость их дублировать в разных тестах, да, лучше выносить, понижая выразительность тестов и не устраняя недостаток низкой повторной используемости юнита (т.е. нарушить обсуждаемое правило Явность тестовых данных). Если же цель проверять не только поведение юнита, но и за счет лаконичности теста удостоверяться в хорошем дизайне продакшен кода, то следует стремиться делать тесты короткими, причем не за счет косвенности данных, а за счет малых объемов получаемых данных в самих юнитах. В конечном итоге, тест — это показательный клиент нашего кода. Чем сложнее нам вызывать код нашего юнита, тем сложнее будет всем будущим клиентам. В этом одно из очарований TDD — проецируй будущих клиентов на себя самого.

[dmitriy_t]

В целом согласен.

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