Поиск
Закладки
Озвучивание недоступно Озвучить книгу
Изменить режим чтения
Изменить размер шрифта
Оглавление
Для озвучивания и цитирования книги перейдите в режим постраничного просмотра.
Искусство автономного тестирования с примерами на C#. 2-е издание

ЧАСТЬ IV. Проектирование и процесс

Предыдущая страница

Следующая страница

ЧАСТЬ IV. Проектирование и процесс
На предыдущую главу Предыдущая глава
оглавление
Следующая глава На следующую главу

Оглавление

ЧАСТЬ IV. Проектирование и процесс-
Глава 9. Внедрение автономного тестирования в организации
9.1. Как стать инициатором перемен
9.1.1. Будьте готовы к трудным вопросам
9.1.2. Убедите сотрудников: сподвижники и противники
9.1.3. Выявите возможные пути внедрения
9.2. Пути к успеху
9.2.1. Партизанское внедрение (снизу вверх)
9.2.2. Обеспечение поддержки руководства (сверху вниз)
9.2.3. Привлечение организатора со стороны
9.2.4. Наглядная демонстрация прогресса
9.2.5. Постановка конкретных целей
9.2.6. Осознание неизбежности препятствий
9.3. Пути к провалу
9.3.1. Отсутствие движущей силы
9.3.2. Отсутствие политической поддержки
9.3.3. Плохая организация внедрения и негативные первые впечатления
9.3.4. Отсутствие поддержки со стороны команды
9.4. Факторы влияния
9.5. Трудные вопросы и ответы на них
9.5.1. Насколько автономное тестирование замедлит текущий процесс?
9.5.2. Не станет ли автономное тестирование угрозой моей работе в отделе контроля качества?
9.5.3. Откуда нам знать, что автономные тесты и вправду работают?
9.5.4. Есть ли доказательства, что автономное тестирование действительно помогает?
9.5.5. Почему отдел контроля качества по-прежнему находит ошибки?
9.5.6. У нас полно кода без тестов: с чего начать?
9.5.7. Мы работаем на нескольких языках, возможно ли при этом автономное тестирование?
9.5.8. А что, если мы разрабатываем программно-аппаратные решения?
9.5.9. Откуда нам знать, что в тестах нет ошибок?
9.5.10. Мой отладчик показывает, что код работает правильно. К чему мне еще тесты?
9.5.11. Мы обязательно должны вести разработку через тестирование?
9.6. Резюме
Глава 10. Работа с унаследованным кодом
10.1. С чего начать добавление тестов?
10.2. На какой стратегии выбора остановиться
10.2.1. Плюсы и минусы стратегии "сначала простые"
10.2.2. Плюсы и минусы стратегии "сначала трудные"
10.3. Написание интеграционных тестов до рефакторинга
10.4. Инструменты, важные для автономного тестирования унаследованного кода
10.4.1. Изолируйте зависимости с помощью JustMock или Typemock Isolator
10.4.2. Используйте JMockit при работе с унаследованным кодом на Java
10.4.3. Используйте Vise для рефакторинга кода на Java
10.4.4. Используйте приемочные тесты перед началом рефакторинга
10.4.5. Прочитайте книгу Майкла Фэзерса об унаследованном коде
10.4.6. Используйте NDepend для исследования продуктового кода
10.4.7. Используйте ReSharper для навигации и рефакторинга продуктового кода
10.4.8. Используйте Simian и TeamCity для обнаружения повторяющегося кода (и ошибок)
10.5. Резюме
Глава 11. Проектирование и тестопригодность
11.1. Почему я должен думать о тестопригодности в своем проекте?
11.2. Цели проектирования с учетом тестопригодности
11.2.1. По умолчанию делайте методы виртуальными
11.2.2. Проектируйте на основе интерфейсов
11.2.3. По умолчанию делайте классы незапечатанными
11.2.4. Избегайте создания экземпляров конкретных классов внутри методов, содержащих логику
11.2.5. Избегайте прямых обращений к статическим методам
11.2.6. Избегайте конструкторов и статических конструкторов, содержащих логику
11.2.7. Отделяйте логику объектов-одиночек от логики их создания
11.3. Плюсы и минусы проектирования с учетом тестопригодности
11.3.1. Объем работы
11.3.2. Сложность
11.3.3. Раскрытие секретной интеллектуальной собственности
11.3.4. Иногда нет никакой возможности
11.4. Альтернативы проектированию с учетом тестопригодности
11.4.1. К вопросу о проектировании в динамически типизированных языках
11.5. Пример проекта, трудного для тестирования
11.6. Резюме
11.7. Дополнительные ресурсы
Данный блок поддерживает скрол*