Проектируй для тестирования

      Редко бывает достаточно, что наши системы работают. Обычно нам также нужно знать, что они работают хорошо. Это положение может показаться тривиальным, но из него есть следствия для того, как нам организовать свою работу.
      На уровне выявления требований мы можем обследовать определенный участок проблемной области, который, как мы предполагаем, может стать источником проблем, даже не зная, собрали ли мы всю относящуюся к проблеме информацию. Для повышения уверенности, что мы ничего не упустили, нам нужно пристально посмотреть пошире, чтобы увидеть, куда что уходит, и откуда что приходит. Мы должны найти способ представления этих потоков, чтобы можно было охватить одним взглядом большую картину. Стопки прозы или толстые папки Диаграмм Потоков Данных здесь совсем не помогут (хотя они могут пригодиться где-то в другом месте проекта), поскольку они не позволят нам увидеть одним взглядом, что нет потерянных концов. Если мы можем убедиться, что нет потерянных концов, то мы с основанием можем быть уверены, что здесь нет скрытых ужасов, которые мы обнаружим во время реализации. Это пример технологии картостроителя для очерчивания проблемы.
      На архитектурном и детальном уровнях проектирования применяется та же идея. Рассматривая наш проект, мы представляем себе наши идеи как можно большим числом способов и проверяем, сможем ли мы их разрушить. Это важно, что мы используем некоторые черты проекта, такие как число возможных состояний на входе, чтобы показать, что система, которую мы проектируем, будет устойчива во всех случаях, показав, что мы рассмотрели все случаи. Это не означает, что мы пытаемся просмотреть все варианты -- вместо этого мы находим средства сгруппировать эти варианты, и показать, что мы рассмотрели все группы.
      При пошаговой отладке с помощью символьного графического отладчика в каждой точке принятия решения нам следует рассмотреть все обстоятельства, при которых принят путь, который мы выбираем, и также следует проследить все другие варианты путей.
      Во всех этих ситуациях проектирование для тестирования начинается с разбиения нашей работы на уровни так, чтобы ее корректность была доступна для проверки. В свете этого интересно рассмотреть, что мы подразумеваем под математическим доказательством. Предназначение доказательства обычно описывают как то, что показывает, что утверждение имеет место. Это действие-центрический взгляд на вещи, присущий паковщикам. Описание предназначения доказательства с точки зрения картостроителя состоит в том, что оно показывает нам утверждение в новом свете, в котором истинность утверждения очевидна для проверки. Для картостроителей доказательство не просто устанавливает факт, оно так же увеличивает наше понимание. Недавно мы видели полученные с помощью компьютера доказательства, которые удовлетворяют целям паковщика, но не дают ничего для целей картостроителя. Эти доказательства, поскольку они не используют силу, которая приходит от понимания, слабее. Так ли необходимо, чтобы корректность кода (оставим в стороне архитектуру компьютера), который выполняет поиск, была очевидна для проверки?
      Мудрые архитекторы обычно разделяют свои проекты на уровни так, что прослеживаются отдельные дискретные стадии при переходе от кода, взаимодействующего с пользователем, к коду, взаимодействующему с операционной системой. Каждый из этих уровней предоставляет возможность написать небольшое тестовое приложение. Обычно этими возможностями следует воспользоваться, поскольку хотя это, как может показаться, и вызывает рост стоимости, выявление ошибок, которые не имеют хорошо определенных тестовых точек, может неимоверно осложнить фазу окончательного тестирования и отнимет кучу времени. Чтобы полностью воспользоваться этими тестовыми возможностями, нам следует предусмотреть тестирование при определении API для наших уровней. Можно ли упростить определения API так, что мы сможем уменьшить количество всех возможных вызовов, которые не имеют смысл? Каждый уровень обязан проверять свой вход, либо, если время очень критично, требовать предварительно выверенных входных значений. Тестирование должно гарантировать, что эта логика работает в соответствии условиями функционирования этого уровня. Если API можно упростить, то одновременно автоматически упрощаются требования к тестированию.
      Соображения, которые применимы к уровням, также применимы к процессам времени исполнения. Большинство нетривиальных систем требуют нескольких процессов для взаимодействия как внутри отдельной платформы, так и через сеть. Функциональность этих процессов должна быть распределена таким образом, чтобы их можно было протестировать, в идеале изолированно -- из командной строки или с помощью скрипта.
      Иногда нам не удается избежать внесения неоднородности (разрывности) решения, которая отсутствует в проблеме. Например, если наша база данных настолько велика, что мы должны распределить ее по нескольким машинам (и имеющаяся у нас коммерческая СУБД не обеспечивает такой возможности), то нам нужно распознать те точки, где должна измениться логика наших программ, чтобы работать на другой системе, и убедиться (тестированием), что это изменение проведено правильно.
      У разработчиков объектных систем есть особенно простая стратегия автоматизации тестирования. Каждый класс (или ключевые классы, по решению архитектора) может иметь соответствующий класс, заданный так, что подменяет (эмулирует) методы системного класса. Это так хорошо работает потому, что описание этого класса стимулирует тестирование внешнего интерфейса класса в стандартизованном и хорошо определенным формате (в чем заключается суть объектов). Поэтому каждый класс может сопровождаться собственным тестовым кодом, который просто нужно заключить в небольшую обрамляющую программку для автоматизации тестирования. Эти тестовые классы иногда называют классами "янь" ("yang"), а поставляемые классы называют соответственно классами "инь" ("yin").
      Когда имеется автоматизированный тест, можно получить два преимущества. Первое заключается в том, что тесты можно прогонять каждую ночь, как составляющую процесса компиляции. Это позволяет программистам оставаться в хорошем настроении, когда прийдя на работу они находят e-mail от среды разработки, говорящий, что все, что команда разработала до сего момента, все еще правильно работает. Когда сообщение говорит, что есть проблемы, то не приходится тратить дни на то, чтобы найти, что же не так с их новым уровнем, когда проблема на самом деле лежит двумя уровнями ниже. Второе преимущество автоматизированного тестирования кода состоит в том, что оно не запаздывает относительно разработки, как это бывает с документацией. Если автоматизированный тест прошел компиляцию, компоновку и выполнение, то мы знаем, что описание поведения протестированного кода правильное.
      Эти идеи определения и исполнения автоматизированных тестов особенно важны для очень сложных проектов, где динамическое управление конфигурацией и средства инкрементной компиляции из научно-фантастических книг позволяют сотням разработчиков работать как проклятым мартышкам на кокаине без сна и отдыха. (Сказанное -- авторская риторика).
      Контрольные проверки и прогон автоматизированных тестов снизу доверху не следует рассматривать как помеху в работе -- это очень дешевый путь получения подтверждения прочности фундамента. Как дополнительное преимущество, такие события становятся праздниками команды, по мере того как модуль за модулем, уровень за уровнем говорят об успешной компиляции и прохождении теста на рабочей станции менеджера. На таких праздниках команда может естественным образом взглянуть на все, чего они достигли к этому моменту, поскольку самый первый праздник может состоять просто в компиляции и запуске программы `Hello, world!' и доказательстве, что компилятор работает правильно, а последний дает в результате работающий продукт, который поставляется заказчику и в котором достигнуты все цели.

Даты, деньги, единицы измерения и проблема Y2K

      Область, где тестирование (и сбои) могут быть существенно уменьшены уменьшением сложности системы -- это распознавание неоднородностей (прерывности) в проблемной области и избежание ее более глубоким представлением. Что это означает на практике? Один из примеров -- это отсчет времени и переход на летнее время. Время обычно считается секунда за секундой, а планета не дергается на орбите каждую весну и осень. Поэтому, даже если нормативные документы говорят о переходах на зимнее и летнее время, нет необходимости отражать эти переходы в системе на уровнях более нижних чем уровень интерфейса пользователя, в котором должна быть предусмотрена функция, метод или нечто, названное LocalAdjustTime() или как-то похоже. UNIX содержит прекрасную поддержку этих вещей, но печально мало мест, где она правильно используется.
      Тот же подход применим и к временным зонам. Ваши пользователи могут прекрасно работать по всему миру и желать использовать местное время, но ваша сеть повсеместно должна использовать гринвичское время (GMT, или UTC), и все даты и времена файлов должны проставляться соответственно. Проблемы упорядочивания по дате файлов, созданных на компьютерах с по-разному установленными часами, поглощают у программистов много часов. Однажды менеджер международной сети пошла в магазин и купила сорок отвратительных, в стиле 50-х годов, одинаковых часов и коробку батареек. Весь следующий год, при посещении очередного удаленного офиса, она устанавливала на часах правильное время по Гринвичу (GMT) и вешала их на стену. В конце того года постоянные проблемы, связанные с трудностями упорядочения файлов, магически исчезли, поскольку у каждого оператора перед глазами было огромных размеров напоминание, какое время нужно установить на системных часах при перезагрузке.
      Другим примером того, как избежать неоднородности в проблемной области, могут послужить два вида денег, которые нравится иметь большинству стран. В фунте всегда 100 пенсов, а в долларе 100 центов, или просто храните пенсы или центы, а если пользователь хочет, чтобы перед последними двумя цифрами печаталась десятичная точка, достаточно поставить 2 где-то в базе данных и использовать процедуру, которая просматривает базу данных. Но такие чувствительные валюты, как песеты и лиры не имеют вторых денег, вызывая проблемы, поскольку нужно помнить, что не нужно печатать десятичную точку...
      Трудности, ассоциирующиеся с проблемой 2000 года, постоянно создают порог, о который то и дело вновь и вновь спотыкаются программисты. Языки программирования предоставляют типы данных, поскольку внутри типа имеется произвольный набор операций, которые можно использовать или нет, и если приходится читать код, а операции там встречаются, то их можно увидеть. Объектно-ориентированные языки расширяют эти средства для любых данных, которыми мы желаем таким образом управлять, предоставляя Абстрактные Типы Данных (ADT). Реальная трудность с 2000 годом не в том, что многие программисты кодировали год двумя цифрами -- в те времена требовалось экономить память, а многие дошедшие до 2000 года программы очень старые. Проблема в том, что некоторые программисты берут эти две цифры и вставляют их где ни попадя без использования подходящей подпрограммы, макроса или даже фрагмента кода, чтобы сделать поправку. Это означает, что для того, чтобы решить проблему 2000 года в этих ужасно переплетенных старых программах требуется прочитать и понять каждую отдельную строку.

Безопасность

      В разных местах разная потребность в безопасности. Для некоторых это неизбежное следствие природы бизнеса. Многие военные и коммерческие операции действительно нуждаются в предотвращении раскрытия того, что происходит. Но многие несуразицы происходят из-за путаницы в понимании назначения безопасности, и это предмет обсуждения этого раздела. Как это было в этой работе уже много раз, ситуации и технологии усиления безопасности проявляются повсюду. Здесь мы сконцентрируемся на некоторых курьезах обычной безопасности.
      Во-первых, следует различать требования безопасности продуктов, которые исходят из потребностей пользователя, и безопасности, требующейся собственно в среде разработки. Это может быть взаимосвязано, например, безопасность продукта зависит от конфиденциальности исходного кода, но взаимосвязь не означает эквивалентности. Не добавляйте в продуктах средства "засекречивания" принудительно или по привычке. Так ли необходимо связывать пароль с каждым идентификатором пользователя в вашем продукте? Нужен ли вам идентификатор пользователя вообще? Нельзя ли использовать для доступа к несекретной информации идентификатор "guest", не требующий пароля? Каждый пароль в вашем продукте вы должны запоминать и поддерживать, уменьшая эргономическую живучесть и увеличивая стоимость владения, ведь эти красотки наверняка забудут свои пароли.
      Далее, существует два вида угроз безопасности: злонамеренные и по небрежности. Вашему продукту может потребоваться защита от злонамеренных угроз, но если вам требуется защита вашей собственной среды разработки от злонамеренных угроз изнутри (мы предполагаем, что вы растете и у вас уже есть брандмауэр), то у вас гораздо большие проблемы, и они не решаются просто установкой запрета доступа к нескольким файлам. Поэтому забудьте о злонамеренных угрозах на работе. Что касается угроз по небрежности, типа случайного уничтожения всего дерева исходных текстов проекта, то ведь у вас есть резервная копия, не правда ли? Навязывание дорогостоящих накладных расходов на безопасность каждой операции в среде разработки для защиты от "катастроф", которые, если произойдут, оказываются пустяками -- это ложный путь. По мере того, как программисты все лучше осваивают персональный послойный процесс, даже эти незначительные ошибки происходят все реже, а разработка совместно используемых мысленных моделей и картостроительный жаргон в команде означают, что неформальный "этикет" разработки уже усвоен, как возглас "Реинициализация тестовой базы данных -- все в порядке?" перед очисткой засоренных тестовых данных. Эти вопросы как элементы этикета -- единственный приемлемый возглас в ненавистных офисах с открытой планировкой, и это единственный разумный довод их существования. Но, тем не менее, это недостаточный довод.
      Поэтому не блокируйте вашу среду разработки до состояния, когда изменение хоть чего-нибудь требует присутствия каждого члена команды, чтобы ввести свои пароли. Не создавайте и не приспосабливайте системы управления конфигурацией, которые делают разработчиков беспомощными в 8 часов вечера, когда они все еще на работе, но не могут получить исправляемый файл, чтобы прочитать и разобраться. Это не только напрямую тормозит ваш проект: это также дает печальный эмоциональный опыт, который вы навьючиваете на самое высокомотивированное животное в коммерческом мире -- программиста в Режиме Глубокого Хака. Чем он вас так обидел?
      И наконец, не позволяйте затуманить ваши мозги ни одному элементу из веры паковщиков, в то, что мы должны знать точно кто, когда и что абсолютно обо всем. Если ваш проект -- это команда, координируемая этикетом и формализованная по необходимости, у вас есть шанс. Если это базар, регулируемый детальными инструкциями, то вы обречены.