Программирование. Принципы и практика использования C++ Исправленное издание - Бьёрн Страуструп

        if (*p<*prev) throw Not_ordered();

    }

  }

  // теперь выполняем функцию binary_search

}

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

26.4. Проектирование с учетом тестирования

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

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

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

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

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

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

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

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

26.5. Отладка

26.6. Производительность

Как же узнать, что программа (или ее модуль) является достаточно эффективной? Абстрактно на этот вопрос ответить невозможно. Современное аппаратное обеспечение работает настолько быстро, что для многих программ этот вопрос вообще не возникает. Нам встречались программы, намеренно скомпилированные в режиме отладки (т.е. работающие в 25 раз медленнее, чем требуется), чтобы повысить возможности диагностики ошибок, которые могут возникнуть после их развертывания (это может произойти даже с самым лучшим кодом, который вынужден сосуществовать с другими программами, разработанными “где-то еще”).

Следовательно, ответ на вопрос “Достаточно ли эффективной является программа?” звучит так: “Измерьте время, за которое выполняется интересный тест”. Очевидно, что для этого необходимо очень хорошо знать своих конечных пользователей и иметь представление о том, что именно они считают интересным и какую продолжительность работы считают приемлемой для такого интересного теста. Логически рассуждая, мы просто отмечаем время на секундомере при выполнении наших тестов и проверяем, не работали ли они дольше разумного предела. С помощью функции clock() (раздел 26.6.1) можно автоматически сравнивать продолжительность выполнения тестов с разумными оценками. В качестве альтернативы (или в дополнение) можно записывать продолжительность выполнения тестов и сравнивать их с ранее полученными результатами. Этот способ оценки напоминает регрессивное тестирование производительности программы.

Некто предложил использовать подходящую функцию.

double row_sum(Matrix<double,2> m, int n); // суммирует элементы в m[n]

Потом этот некто стал использовать эту функцию для того, чтобы сгенерировать вектор сумм, где v[n] — сумма элементов в первых n строках.

double row_accum(Matrix<double,2> m, int n) // сумма элементов

                                            // в m[0:n)

{

  double s = 0;

  for (int i=0; i<n; ++i) s+=row_sum(m,i);

  return s;

}

 // вычисляет накопленные суммы по строкам матрицы m:

 vector<double> v;

 for (int i = 0; i<m.dim1(); ++i)

 v.push_back(row_accum(m,i+1));

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