Почему выбирают единицу вместо нуля в тестовых значениях с учетом особенностей языков программирования

Что проверяют

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

Как отвечать

Единица и ноль не альтернативы, это соседние точки одной границы, и проверяют обе. Единицу берут за основу позитивных данных, потому что ноль слишком похож на отсутствие значения: он совпадает со значением по умолчанию у числовых типов и потому маскирует ошибки. Поле не пришло, переменная не проинициализирована, счётчик не посчитан, а тест зелёный, потому что ждали как раз ноль.

Дальше про языки, в этом и суть вопроса:

• в Python и JavaScript ноль ложен в логическом контексте, поэтому if not count и if (!count) срабатывают и на нуле, и на пустой строке, и на отсутствующем значении;
• в Java ноль это значение по умолчанию для примитивов, а у обёртки там null, и распаковка даёт исключение;
• в Go у каждого типа есть нулевое значение, и отличить «не задано» от «задано нулём» без указателя нельзя;
• в C ноль это одновременно и ложь, и нулевой указатель.

Отсюда практика: идентификаторы в фикстурах начинают с единицы, а ноль проверяют отдельно, как граничный случай наравне с пустым списком и пустой строкой.

Где спотыкаются

Сводят ответ к тому, что единица это истина, а ноль ложь. Это разговор про булеву алгебру, а спрашивают про поведение системы на пустых данных.

Второе: выбрасывают ноль из набора совсем. Именно на нём ломаются деление, среднее значение, проценты, постраничная выдача и пустой список, а сообщение об ошибке нередко оказывается непонятным пользователю.

Третье: берут одно значение и считают границу проверенной. Нужна сама граница и точки по обе стороны от неё, иначе тест не отличит строгое сравнение от нестрогого и пропустит ошибку на единицу.