- •1. Оформление кода. Венгерская нотация и нотация Lower Case.
- •2. Автоматические системы документирования. Команды
- •3. Понятие контроля версий проекта. Основные системы контроля версий.
- •4. Система Git. Основные команды Git.
- •5. Модели разработки программного обеспечения. Водопад.
- •6. Модели разработки программного обеспечения. Спираль.
- •7. Модели разработки программного обеспечения. V-образная модель.
- •10. Google Test. Нефатальные утверждения.
- •8. Google Test. Утверждения Google Test.
- •9. Google Test. Фатальные утверждения.
- •11. Разработка через тестирование.
- •12. Объектно-ориентирование программирование.
- •13. Парадигмы объектно-ориентированного программирования.
- •14. Классы и объекты.
- •15. Поля и методы класса.
- •16. Методы класса. Методы set и get.
- •17. Правила доступа и оформления при ооп.
- •18. Конструкторы и деструкторы.
- •19. Конструктор по умолчанию.
- •Пример Конструктора по умолчанию
- •20. Использование спецификаторов доступа.
- •21. Инкапсуляция. Разделение интерфейса и реализации в проекте.
- •22. Защита от повторной компиляции. Назначение. Пример.
- •23. Одиночное и множественное наследование.
- •24. Виртуальная функция. Чистая виртуальная функция.
- •25. Абстрактный класс.
- •26. Полиморфизм.
- •27. Перегрузка бинарных операторов.
- •28. Перегрузка унарных операторов.
- •29. Перегрузка функций.
- •30. Перегрузка операторов. Постфиксная и префиксные формы.
- •31. Технология rad.
- •32. Интегрированная среда разработки.
- •33. Rad. Свойства, события и методы.
- •34. Rad. Стандартная библиотека компонент vcl. Иерархия vcl.
- •35. Rad. События мыши.
- •36. Canvas. Основные методы Canvas.
- •37. Canvas. Основные свойства tBrush.
- •38. Canvas. Основные свойства tPen.
- •39. Пользовательские диалоги.
- •40. Диалог InputBox.
- •InputBox
- •InputBox(prompt[, title] [, default] [, xpos] [, ypos]),
- •41. Тип данных UnicodeString. Основные методы UnicodeString.
- •42. Понятие ошибочной ситуации.
- •43. Исключительная ситуация. Генерация, раскручивание стека и перехват при возникновении исключений.
- •1. Обработка ошибок
- •2. Генерация и перехват исключений
- •45. Понятие структуры данных. Состав элемента структуры.
- •46. Структуры данных: стек, очередь, список.
- •47. Структуры данных: множества, мультимножества, дерево.
- •48. Алгоритмы, контейнеры и итераторы.
- •49. Контейнер как структура данных.
- •Как выбрать контейнер?
- •50. Методы контейнеров.
- •51. Stl. Контейнер list.
- •52. Stl. Контейнер vector.
- •53. Slt. Контейнер map.
- •54. Stl. Контейнер set.
- •55. Основные алгоритмы stl. Алгоритм find.
- •56. Основные алгоритмы stl. Алгоритм max_element.
- •57. Основные алгоритмы stl. Алгоритм sort.
- •58. Основные алгоритмы stl. Алгоритм reverse.
8. Google Test. Утверждения Google Test.
Google Test — это фреймворк от Google для юнит-тестирования кода на С++.
Утверждения в Google Test являются макросами, схожими с вызовами функций. Вы тестируете класс или функцию, делая логические постулаты (утверждения) об их ожидаемом поведении. Когда такой постулат нарушается, Google Test печатает имя файла и номер строки, где произошел сбой. Также выводится диагностическое сообщение об ошибке. Вы можете задавать свои собственные дополнительные сообщения, которые будут добавлены к стандартному.
Утверждения бывают двух типов, схожих по названию, но по разному влияющих на выполнение текущего теста. ASSERT_* генерируют фатальные ошибки, при возникновении которых выполнение текущей функции прерывается. Другой тип, EXPECT_*, генерирует "мягкие", нефатальные ошибки, которые не прерывают текущую функцию. Такие утверждения являются более предпочтительными, так как дают возможность обнаружить сразу несколько проблем в тесте. Однако вам следует использовать ASSERT_*, если уже не имеет смысла продолжать тест после сбоя.
Когда показавший ошибку ASSERT_* немедленно прерывает выполнение текущей функции, возможно, что часть кода, ответственного за чистку мусора и освобождение ресурсов после теста, не будет выполнена, что может привести к утечкам памяти. В зависимости от типа утечки может и не стоит заботиться о них в данном случае, но надо быть готовым к возможным сообщениям об ошибках от систем проверки динамически распределенной памяти.
Чтобы вывести свое собственное сообщение об ошибке, просто используйте макрос утверждения как стандартный поток и оператор<<. Например:
ASSERT_EQ(x.size(), y.size()) << "Длина вектора x не равна длине вектора y"; for (int i = 0; i < x.size(); ++i) { EXPECT_EQ(x[i], y[i]) << "Вектора x и y отличаются по индексу " << i; }
Все, что может быть выведено в поток ostream можно послать подобным же образом в макрос утверждения. В частности, строки языка С и объекты string. Если печатается широкая строка (wchar_t*, TCHAR* в режиме UNICODE в Windows, или std::wstring), то она будет преобразована в кодировку UTF-8.
9. Google Test. Фатальные утверждения.
Google Test — это фреймворк от Google для юнит-тестирования кода на С++. Общей архитектурой он слегка напоминает общепринятые boost::test и CppUnit, хотя слегка отличается в деталях (как по мне — в лучшую сторону)
Утверждения бывают фатальные и не фатальные. Фатальные макросы вида ASSERT_xxx приводят к остановке процесса тестирования, а нефатальные (или мягкие) утверждения вида EXPECT_xxx позволяют довести тесты до конца, просто выводя информацию об ошибке.
10. Google Test. Нефатальные утверждения.
Google Test — это фреймворк от Google для юнит-тестирования кода на С++. Общей архитектурой он слегка напоминает общепринятые boost::test и CppUnit, хотя слегка отличается в деталях (как по мне — в лучшую сторону)
EXPECT_*, генерирует "мягкие", нефатальные ошибки, которые не прерывают текущую функцию. Такие утверждения являются более предпочтительными, так как дают возможность обнаружить сразу несколько проблем в тесте.
