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

  Важно ли это? Мы считаем, что это чрезвычайно важно. Во-первых, это облегчает тестирование, а без систематического тестирования трудно серьезно рассуждать о корректности. Во-вторых, это обеспечивает переносимость программы. Рассмотрим следующий сценарий. Вы организовали небольшую компанию и написали ваше первое приложение для системы Apple, поскольку (так уж случилось) вам нравится именно эта операционная система. В настоящее время дела вашей компании идут успешно, и вы заметили, что большинство ваших потенциальных клиентов выполняют свои программы под управлением операционной систем Windows или Linux. Что делать? При простой организации кода с командами графического интерфейса (Apple Mac), разбросанными по всей программе, вы будете вынуждены переписать всю программу. Эта даже хорошо, потому что она, вероятно, содержит много ошибок, не выявленных в ходе несистематического тестирования. Однако представьте себе альтернативу, при которой главная программа отделена от графического пользовательского интерфейса (для облегчения систематического тестирования). В этом случае вы просто свяжете другой графический пользовательский интерфейс со своими интерфейсными классами (транслятор на диаграмме), а большинство остального кода системы останется нетронутым.

  На самом деле эта схема представляет собой пример использования “тонких” явных интерфейсов, которые явным образом отделяют части программы друг от друга. Это похоже на использование уровней, которые мы видели в разделе 12.4. Тестирование усиливает желание разделить программу на четкие отдельные модули (с интерфейсами, которые можно использовать для тестирования).

<p id="AutBody_Root524"><strong>26.3.5. Тестирование классов</strong></p>

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

class Shape { // задает цвет и стиль, хранит последовательность линий

public:

  void draw const;                 // задает цвет и рисует линии

  virtual void move(int dx, int dy); // перемещает фигуру

                                     // на +=dx и +=dy

  void set_color(Color col);

  Color color const;

  void set_style(Line_style sty);

  Line_style style const;

  void set_fill_color(Color col);

  Color fill_color const;

  Point point(int i) const; // доступ к точкам без права

                            // модификации

  int number_of_points const;

  virtual ~Shape { }

protected:

  Shape;

  virtual void draw_lines const; // рисует соответствующие точки

  void add(Point p);               // добавляет точку p

  void set_point(int i,Point p);   // points[i]=p;

private:

  vector points; // не используется всеми

  // фигурами

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

  Line_style ls;

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

  Shape(const Shape&);  // предотвращает копирование

  Shape& operator=(const Shape&);

};

Как приступить к тестированию этого класса? Сначала рассмотрим, чем класс Shape отличается от функции binary_search с точки зрения тестирования.

• Класс Shape имеет несколько функций.

• Состояние объекта класса Shape может изменяться (мы можем добавлять точки, изменять цвет и т.д.), т.е. одна функция может влиять на другую.

• Класс Shape имеет виртуальные функции. Другими словами, поведение объекта класса Shape зависит от того, какой производный класс был создан на его основе (если такой класс существует).

• Класс Shape не является алгоритмом.

• Изменение объекта класса Shape может влиять на содержимое экрана.

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT