Идеальный программист. Как стать профессионалом разработки ПО

Пола: «Том, с этим тестом что-то не то».

ensure that the post operation finishes in 2 seconds.

Том: «По-моему, все нормально. Наше требование гласит, что пользователи не должны ждать больше двух секунд. В чем проблема?»

Пола: «Проблема в том, что мы можем гарантировать выполнение требования только в статистическом смысле».

Том: «По-моему, это только слова. В требованиях ясно сказано: две секунды».

Пола: «Верно, и мы можем обеспечить этот результат в 99,5 % случаев».

Том: «Пола, в требовании этого нет».

Пола: «Мы живем в реальном мире. Я не могу предоставить других гарантий».

Том: «Сэм будет в бешенстве».

Пола: «Вообще-то я с ним уже пару раз обсуждала эту тему. Он согласен, если типичная продолжительность операции будет не более двух секунд».

Том: «Ну и как мне писать этот тест? Я же не могу сказать: „операция обычно заканчивается за две секунды“».

Пола: «Сформулируй на статистическом уровне».

Том: «Предлагаешь выполнить операцию тысячу раз и проверить, что она заняла более двух секунд в пяти и менее случаях? Абсурд».

Пола: «Нет, это займет слишком много времени. А как насчет этого?»

execute 15 post transactions and accumulate times.

ensure that the Z score for 2 seconds is at least 2.57[36]

Том: «А что еще за z-показатель?»

Пола: «Так, статистика. А как тебе такая формулировка?»

execute 15 post transactions and accumulate times.

ensure odds are 99.5 % that time will be less than 2 seconds[37]

Том: «Да, это уже понятнее, но можно ли доверять математике?»

Пола: «Я обязательно включу все промежуточные вычисления в отчет по тестированию, чтобы ты мог проверить вычисления, если у тебя останутся сомнения».

Том: «Хорошо, меня это устроит».

Приемочные тесты и модульные тесты

Не путайте приемочные тесты с модульными (unit tests). Модульные тесты пишутся программистами для программистов. Они представляют собой формальные архитектурные документы с описанием нижнего уровня структуры и поведения кода. Их читателями являются не бизнесмены, а программисты.

Приемочные тесты создаются бизнесменами для бизнесменов (даже если в конечном итоге их пишете вы, разработчик). Они представляют собой формальные описания требований, определяющие поведение системы с точки зрения бизнеса. Их читателями являются бизнесмены и программисты.

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

Во-первых, даже если они тестируют одно и то же, при этом используются разные пути и механизмы. Модульные тесты углубляются во внутреннюю реализацию системы и вызывают методы конкретных классов. Приемочные тесты обращаются к системе на значительно более высоком уровне – уровне API или даже уровне пользовательского интерфейса. Таким образом, пути выполнения этих тестов сильно различаются.