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

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

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 или даже уровне пользовательского интерфейса. Таким образом, пути выполнения этих тестов сильно различаются.

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

Графический интерфейс трудно определить заранее. Теоретически это возможно, но редко удается сделать хорошо. Дело в том, что эстетика – предмет субъективный, а следовательно, переменчивый. Разработчики любят повозиться со своими графическими интерфейсами, доводить их до ума и шлифовать. Они хотят использовать разные шрифты, цвета, макеты и схемы выполнения операций. Графические интерфейсы находятся в постоянном развитии.

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