Перечислим причины, по которым функция

не содержала таких проверок.

• Условие

нельзя проверить для однонаправленного итератора; например, итератор контейнера не имеет оператора (раздел Б.3.2). В общем, на самом деле хорошего способа проверки того, что пара итераторов определяет последовательность, не существует (начинать перемещение с итератора , надеясь достигнуть итератора , — не самая хорошая идея).

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

(действительная цель выполнения функции заключается не в слепом блуждании по последовательности в поисках значения, как это делает функция ).

Что же мы могли бы сделать? Мы могли бы при тестировании заменить функцию

функцией (впрочем, только для вызовов функции с помощью итераторов произвольного доступа). В качестве альтернативы мы могли бы взять у разработчика функции ее код, чтобы вставить в нее свой фрагмент.

Поскольку смысл условия тест включен зависит от способа организации тестирования (для конкретной системы в конкретной организации), можем оставить его в виде псевдокода: при тестировании своего собственного кода можете просто использовать переменную

. Мы также оставили условие Iter является итератором произвольного доступа в виде псевдокода, поскольку не хотели объяснять свойства итератора. Если вам действительно необходим такой тест, посмотрите тему свойства итераторов (iterator traits) в более подробном учебнике по языку С++.

Приступая к написанию программы, мы знаем, что в итоге она должна быть полной и правильной. Мы также знаем, что для этого ее необходимо тестировать. Следовательно, разрабатывая программу, мы должны учитывать возможности ее тестирования с первого дня. Многие хорошие программисты руководствуются девизом “Тестируй заблаговременно и часто” и не пишут программу, если не представляют себе, как ее тестировать. Размышление о тестировании на ранних этапах разработки программы позволяет избежать ошибок (и помогает найти их позднее). Мы разделяем эту точку зрения. Некоторые программисты даже пишут тесты для модулей еще до реализации самих модулей.

Примеры из разделов 26.3.2.1 и 26.3.3 иллюстрируют эти важные положения.

• Пишите точно определенные интерфейсы так, чтобы вы могли написать для них тесты.

• Придумайте способ описать операции в виде текста, чтобы их можно было хранить, анализировать и воспроизводить. Это относится также к операциям вывода.

• Встраивайте тесты для непроверяемых предположений (assertions) в вызывающем коде, чтобы перехватить неправильные аргументы до системного тестирования.

• Минимизируйте зависимости и делайте их явными.

• Придерживайтесь ясной стратегии управления ресурсами.

С философской точки зрения это можно рассматривать как применение методов модульного тестирования для проверки подсистем и полных систем.

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

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