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

  Последний момент особенно неприятный. По существу, это значит, что мы должны посадить перед компьютером человека, который будет смотреть, правильно ли ведет себя объект класса Shape. Это не соответствует принципам систематичного, воспроизводимого и доступного тестирования. Как указывалось в разделе 26.3.4.1, мы часто прибегаем к разным уловкам, чтобы избежать этого. Однако пока будем предполагать, что существует наблюдатель, который замечает отклонения изображения от требуемого образца.

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

Что мы можем тестировать, а что не можем? Для того чтобы тестировать класс Shape, мы должны попытаться протестировать его как отдельно, так и в сочетании с производными классами. Однако, для того чтобы проверить, что класс Shape работает правильно с конкретным производным классом, мы должны протестировать этот производный класс.

Ранее мы уже отметили, что объект класса Shape имеет состояние (значение), определенное четырьмя данными-членами.

vector points;

Color lcolor; // цвет линий и символов

Line_style ls;

Color fcolor; // цвет заполнения

Все, что мы можем сделать с объектом класса Shape, — внести в него изменения и посмотреть, что произойдет. К счастью, изменить данные-члены можно только с помощью интерфейса, определенного функциями-членами.

Простейшим объектом класса Shape является объект класса Line, поэтому начнем с создания одного такого объекта и внесем все возможные изменения (используя самый наивный стиль тестирования).

Line ln(Point(10,10), Point(100, 100));

ln.draw;  // смотрим, что произошло

// проверка точек:

if (ln.number_of_points != 2)

  cerr << "Неправильное количество точек ";

if (ln.point(0)!=Point(10,10)) cerr << "Неправильная точка 1";

if (ln.point(1)!=Point(100,100)) cerr << "Неправильная точка 2";

for (int i=0; i<10; ++i) { // смотрим на перемещения объекта

  ln.move(i+5,i+5);

  ln.draw;

}

for (int i=0; i<10; ++i) { // проверяем, возвращается ли объект

                           // в исходное положение

  ln.move(i–5,i–5);

  ln.draw;

}

if (point(0)!=Point(10,10))

  cerr << "Неправильная точка 1 после перемещения";

if (point(1)!=Point(100,100))

  cerr << "Неправильная точка 2 после перемещения";

for (int i = 0; i<100; ++i) { // смотрим, правильно ли изменяются

                              // цвета

  ln.set_color(Color(i*100));

  if (ln.color != Color(i*100))

    cerr << "Неправильное значение set_color";

  ln.draw;

}

for (int i = 0; i<100; ++i) { // смотрим, правильно ли изменяется

                              // стиль

  ln.set_style(Line_style(i*5));

  if (ln.style != Line_style(i*5))

  cerr << "Неправильное значение set_style";

  ln.draw;

}

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

Кроме того, мы выясним, что совершенно не обязательно усаживать перед экраном компьютера человека, который отслеживал бы изменения состояния объектов класса Shape. Итак, у нас появляются две альтернативы:

• замедлить работу программы, чтобы за ней мог следить наблюдатель;

• найти такое представление класса Shape, чтобы мы могли читать и анализировать его с помощью программы.

Отметим, что мы еще не тестировали функцию add(Point). Для того чтобы проверить ее, мы, вероятно, должны были бы использовать класс Open_polyline.

26.3.6. Поиск предположений, которые не выполняются