Шаги для взятия для медленной интеграции поблочного тестирования в проект
Сначала убедитесь, что каталог bin вашего mingw находится в вашей среде PATH, поэтому gcc и g++ можно вызывать из командной строки. Затем перейдите в корневой каталог вашего буста, где вы распаковали файлы.
Следуйте этому с помощью bootstrap + b2.exe для сборки. Например, предположим, что вы хотите скомпилировать только часть выражения regex. Следующие команды должны выполнить трюк:
bootstrap gcc
b2 toolset=gcc regex
Вы можете использовать:
b2 --show-libraries
, чтобы получить список модулей, которые вы можете построить индивидуально. Конечно, вы можете собрать их все с помощью всего лишь:
b2 toolset=gcc
Проверьте Boost Invocation для подробного списка доступных опций.
4 ответа
Эффективная работа с устаревшим кодом Майкл Фезерс
Трудно сказать, принесет ли реализация фабричного шаблона хоть какую-то пользу, зависит от того, что делает код :)
Очень сложно начать новые методы разработки в середине проекта. Раньше, когда я работал над проектами, которые не тестировались с самого начала, хорошим подходом было бы установить правило, согласно которому «новый код должен иметь модульные тесты», но не давить на модульные тесты. пишется для старого кода.
Конечно, даже это сложно, когда структура проекта не подходит для тестирования.
Моя лучшая рекомендация - делать это маленькими шагами.
Начните с создания вашего модуля. тестовая сборка, (или проект, или что-то еще) без тестов. Затем найдите одну небольшую область кода, которая достаточно хорошо определена и разделена, и напишите несколько модульных тестов для этой области. Попросите вашего со-кодировщика тоже взглянуть и начать применять некоторые «передовые практики», такие как запуск модульных тестов каждый раз, когда какой-либо код регистрируется (если возможно, автоматически).
Как только вы это заработаете, вы можете медленно начать добавлять.
Ключ медленно. И, как я уже сказал, для начала проще освободить старый код от тестирования. Вы всегда можете вернуться к нему позже, когда ваша команда осознает идею модульного тестирования и научится лучше их писать.
Попросите вашего со-кодировщика тоже взглянуть и начать применять некоторые «передовые практики», такие как запуск модульных тестов каждый раз, когда какой-либо код регистрируется (если возможно, автоматически).Как только вы это заработаете, вы можете медленно начать добавлять.
Ключ медленно. И, как я уже сказал, для начала проще освободить старый код от тестирования. Вы всегда можете вернуться к нему позже, когда ваша команда осознает идею модульного тестирования и научится лучше их писать.
Попросите вашего со-кодировщика тоже взглянуть и начать применять некоторые «передовые практики», такие как запуск модульных тестов каждый раз, когда какой-либо код регистрируется (если возможно, автоматически).Как только вы это заработаете, вы можете медленно начать добавлять.
Ключ медленно. И, как я уже сказал, для начала проще освободить старый код от тестирования. Вы всегда можете вернуться к нему позже, когда ваша команда осознает идею модульного тестирования и научится лучше их писать.
Эффективная работа с устаревшим кодом Майкла Фезерса (также доступен в Safari, если у вас есть подписка) - отличный ресурс для решения вашей задачи. Автор определяет устаревший код как код без модульных тестов и дает практические пошаговые инструкции по партиям консервативных методов - необходимых, поскольку вы работаете без защиты - для проверки кода. Оглавление:
- Часть: I Механика перемен
- Глава 1. Изменение программного обеспечения
- Четыре причины изменить программное обеспечение
- Рискованное изменение
- Глава 2. Работа с обратной связью
- Что такое модульное тестирование?
- Тестирование более высокого уровня
- Тестовые покрытия
- Устаревший алгоритм изменения кода
- Глава 3. Обнаружение и разделение
- Подделка сотрудников
- Глава 4. Модель шва
- Огромный лист текста
- Швы
- Типы швов
- Глава 5. Инструменты
- Автоматизированные инструменты рефакторинга
- Мок-объекты
- Жгуты модульного тестирования
- Общие тестовые комплекты
- Глава 1. Изменение программного обеспечения
- Часть: II Изменение программного обеспечения
- Глава 6. У меня мало времени, и я должен его изменить
- Метод Sprout
- Класс Sprout
- Метод Wrap
- Класс Wrap
- Краткое содержание
- Глава 7. Чтобы внести изменения, потребуется вечность
- Понимание
- Время задержки
- Прерывание зависимостей
- Резюме
- Глава 8. Как добавить функцию?
- Разработка через тестирование (TDD)
- Программирование на основе различий
- Резюме
- Глава 9. Я не могу поместить этот класс в систему тестирования
- Случай раздражающего параметра
- Случай скрытой зависимости
- Случай строительной капли
- Случай раздражающей глобальной зависимости
- Случай ужасных зависимостей включения
- Случай параметра луковицы
- Случай параметра с псевдонимом
- Глава 10. Я не могу запустить этот метод в тестовой системе
- Случай скрытого метода
- Случай "полезной" языковой особенности
- Случай необнаружимого побочного эффекта
- Глава 11. Мне нужно внести изменения. Какие методы мне следует протестировать?
- Рассуждения об эффектах
- Рассуждения вперед
- Распространение эффекта
- Инструменты для анализа эффектов
- Изучение анализа эффектов
- Упрощение набросков эффектов
- Глава 12. Мне нужно сделать много изменений в одном Площадь. Должен ли я разорвать зависимости для всех задействованных классов?
- Точки перехвата
- Оценка схемы с точками защемления
- Ловушки с защемлением
- Глава 13. Мне нужно внести изменения, но я не знаю, какие тесты написать
Характеризационные тесты
- Характеризационные классы
- Целевое тестирование
- Эвристика для написания характеристических тестов
- Глава 14. Зависимости от библиотек убивают меня
- Глава 15. Мое приложение - это все вызовы API
- Глава 16. I Не понимайте код достаточно хорошо, чтобы изменить его
- Примечания / эскизы
- Разметка листинга
- Рефакторинг с нуля
- Удаление неиспользуемого кода
- Глава 17. Мое приложение не имеет структуры
- Рассказывая историю системы
- Обнаженный CRC
- Анализ разговора
- Глава 18. Мой тестовый код мешает
- Соглашения об именах классов
- Местоположение теста
- Глава 19. Мой проект не объектно-ориентированный. Как сделать безопасные изменения?
- Простой случай
- Трудный случай
- Добавление нового поведения
- Использование объектной ориентации
- Все объектно-ориентированные
- Глава 20. Этот класс слишком велик, и я не хочу Это еще больше
- Видение ответственности
- Другие методы
- Движение вперед
- После извлечения класса
- Глава 21. Я меняю один и тот же код повсюду
- Первые шаги
- Глава 22. Мне нужно изменить метод-монстр, но я не могу написать для него тесты
- Разновидности монстров
- Борьба с монстрами с помощью автоматического рефакторинга
- Задача ручного рефакторинга
- Стратегия
- Глава 23. Как узнать, что я ничего не нарушаю?
- Hyperaware Editing
- Single-Goal Editing
- Preserve Signatures
- Lean on the Compiler
- Глава 24. Мы чувствуем себя подавленными. Лучше не будет
- Глава 6. У меня мало времени, и я должен его изменить
- Часть: III Методы устранения зависимостей
- Глава 25. Методы устранения зависимостей
- Параметр адаптации
- Объект метода разделения
- Завершение определения
- Инкапсуляция глобальных ссылок
- Отображение статического метода
- Вызов извлечения и отмены
- Извлечение и переопределение фабричного метода
- Извлечение и переопределение Получатель
- Извлечь реализатор
- Извлечь интерфейс
- Ввести делегатор экземпляра
- Ввести статический установщик
- Подстановка ссылок
- Параметризовать конструктор
- Параметризовать метод
- Примитивизировать параметр
- Функция извлечения
- Выталкивающая зависимость
- Заменить функцию указателем на функцию
- Заменить глобальную ссылку на Getter
- Подкласс и метод переопределения
- Заменить переменную экземпляра
- Переопределение шаблона
- Переопределение текста
- Глава 25. Методы устранения зависимостей
- Приложение: рефакторинг
- Извлечь метод
Как насчет написания серии тестов черного ящика для основных частей вашего кода? Поскольку вы упомянули, что это проект ASP.NET, вы можете использовать фреймворк, например WaitN или Selenium , для автоматизации веб-браузера. Это дает вам базовый набор функций, который должен оставаться постоянным независимо от того, насколько сильно изменяется код.
Когда у вас будет удобное количество тестов, проверяющих высокоуровневую функциональность вашего проекта, я бы начал погружаться в код , и, как упоминает Саймон П. Стивенс, работают медленно . Скачайте (бесплатно!) Копию Refactor! для Visual Basic , поэтому вы сможете автоматически выполнять базовый рефакторинг, такой как Extract Method.