Искусство автономного тестирования с примерами на С# (Ошероув Рой) ; ДМК-Пресс, 2016

Предисловие Роберта С. Мартина ко второму
изданию
Предисловие Майкла Фэзерса ко второму изданию
Вступление
Благодарности
Об этой книге
Предполагаемая аудитория
Структура книги
Графические выделения и загрузка исходного
кода
Требования к программному обеспечению
Автор в сети
Другие проекты Роя Ошероува
Об иллюстрации на обложке
Часть I. Приступая к работе
Глава 1. Основы автономного тестирования
1.1. Определение автономного тестирования, шаг
за шагом
1.1.1.0 важности написания хороших автономных
тестов
1.1.2. Все мы писали автономные тесты (или что-то
в этом роде).
1.2. Свойства хорошего автономного теста
1.3. Интеграционные тесты
1.3.1. Недостатки неавтоматизированных
интеграционных тестов по сравнению с
автоматизированными автономными тестами
1.4. Из чего складывается хороший автономный
тест?
1.5. Пример простого автономного теста
1.6. Разработка через тестирование
1.7. Три основных навыка успешного практика TDD
1.8. Резюме
Глава 2. Первый автономный тест
2.1. Каркасы автономного тестирования
2.1.1. Что предлагают каркасы автономного
тестирования
2.1.2. Каркасы семейства xLlnit
2.2. Знакомство с проектом LogAn
2.3. Первые шаги освоения NUnit
2.3.1. Установка NUnit
2.3.2. Загрузка решения
2.3.3. Использование атрибутов NUnit
2.4. Создание первого теста
2.4.1. Класс Assert
2.4.2. Прогон первого теста в NUnit
2.4.3. Добавление положительных тестов
2.4.4. От красного к зеленому: тесты должны
проходить
2.4.5. Стилистическое оформление тестового кода
2.5. Рефакторинг- параметризованные тесты
2.6. Другие атрибуты в NUnit
2.6.1. Подготовка и очистка
2.6.2. Проверка ожидаемых исключений
2.6.3. Игнорирование тестов
2.6.4. Текучий синтаксис в NUnit
2.6.5. Задание категорий теста
2.7. Проверка изменения состояния системы, а не
возвращаемого значения
2.8. Резюме
Часть II. Основные приемы
Глава 3. Использование заглушек для разрыва
зависимостей
3.1. Введение в заглушки
3.2. Выявление зависимости от файловой системы в
LogAn
3.3. Как можно легко протестировать LogAnalyzer
3.4. Рефакторинг проекта с целью повышения
тестопригодности
3.4.1. Выделение интерфейса с целью подмены
истинной реализации
3.4.2. Внедрение зависимости: внедрение
поддельной реализации в тестируемую единицу
работы
3.4.3. Внедрение подделки на уровне конструктора
(внедрение через конструктор)
3.4.4. Имитация исключений от подделок
3.4.5. Внедрение подделки через установку
свойства
3.4.6. Внедрение подделки непосредственно перед
вызовом метода
3.5. Варианты рефакторинга
3.5.1. Использование выделения и
переопределения для создания поддельных
результатов
3.6. Преодоление проблемы нарушения
инкапсуляции
3.6.1. internal и [InternalsVisibleTo]
3.6.2. Атрибут [Conditional]
3.6.3. Использование директив #if и #endif для
условной компиляции
3.7. Резюме
Глава 4. Тестирование взаимодействий с помощью
подставных объектов
4.1. Сравнение тестирования взаимодействий с
тестированием на основе значений и состояния
4.2. Различия между подставками и заглушками
4.3. Пример простой рукописной подставки
4.4. Совместное использование заглушки и
подставки
4.5. Одна подставка на тест
4.6. Цепочки подделок: заглушки, порождающие
подставки или другие заглушки
4.7. Проблемы рукописных заглушек и подставок
4.8. Резюме
Глава 5. Изолирующие каркасы генерации
подставных объектов
5.1. Зачем использовать изолирующие каркасы?
5.2. Динамическое создание поддельного объекта
5.2.1. Применение NSubstitute в тестах
5.2.2. Замена рукописной подделки динамической
5.3. Подделка значений
5.3.1. Встретились в тесте подставка, заглушка и
священник
5.4. Тестирование операций, связанныхс событием
5.4.1. Тестирование прослушивателя события
5.4.2. Тестирование факта генерации события
5.5. Современные изолирующие каркасы для .NET
5.6. Достоинства и подводные камни изолирующих
каркасов
5.6.1. Каких подводных камней избегать при
использовании изолирующих каркасов
5.6.2. Неудобочитаемый тестовый код
5.6.3. Проверка не того, что надо
5.6.4. Наличие более одной подставки в одном
тесте
5.6.5. Избыточное специфицирование теста
5.7. Резюме
Глава 6. Внутреннее устройство изолирующих
каркасов
6.1. Ограниченные и неограниченные каркасы
6.1.1. Ограниченные каркасы
6.1.2. Неограниченные каркасы
6.1.3. Как работают неограниченные каркасы на
основе профилировщика
6.2. Полезные качества хороших изолирующих
каркасов
6.3. Особенности, обеспечивающие
неустареваемость и удобство пользования
6.3.1. Рекурсивные подделки
6.3.2. Игнорирование аргументов по умолчанию
6.3.3. Массовое подделывание
6.3.4. Нестрогое поведение подделок
6.3.5. Нестрогие подставки
6.4. Антипаттерны проектирования в изолирующих
каркасах
6.4.1. Смешение понятий
6.4.2. Запись и воспроизведение
6.4.3. Липкое поведение
6.4.4. Сложный синтаксис
6.5. Резюме
ЧАСТЬ III. Тестовый код
Глава 7. Иерархии и организация тестов,
7.1. Прогон автоматизированных тестов входе
автоматизированной сборки
7.1.1. Анатомия скрипта сборки
7.1.2. Запуск сборки и интеграции
7.2. Распределение тестов по скорости и типу
7.2.1. Разделение автономных и интеграционных
тестов и человеческий фактор
7.2.2. Безопасная зеленая зона
7.3. Тесты должны храниться в системе управления
версиями
7.4. Соответствие между тестовыми классами и
тестируемым кодом
7.4.1. Соответствие между тестами и проектами
7.4.2. Соответствие между тестами и классами
7.4.3. Соответствие между тестами и точками
входа в единицу работы
7.5. Внедрение сквозной функциональности
7.6. Разработка API тестов приложения
7.6.1. Наследование тестовых классов
7.6.2. Создание служебных классов и методов для
тестов
7.6.3. Извещение разработчиков об имеющемся API
7.7. Резюме
Глава 8. Три столпа хороших автономных тестов
8.1. Написание заслуживающих доверия тестов
8.1.1. Когда удалять или изменять тесты
8.1.2. Устранение логики из тестов
8.1.3. Тестирование только одного результата
8.1.4. Разделение автономных и интеграционных
тестов
8.1.5. Проводите анализ кода, уделяя внимание
покрытию кода
8.2.Написание удобных для сопровождения тестов
8.2.1. Тестирование закрытых и защищенных
методов
8.2.2. Устранение дублирования
8.2.3. Применение методов подготовки без
усложнения сопровождения
8.2.4. Принудительная изоляция тестов
8.2.5. Предотвращение нескольких утверждений о
разных функциях
8.2.6. Сравнение объектов
8.2.7. Предотвращение избыточного
специфицирования
8.3. Написание удобочитаемых тестов
8.3.1. Именование автономных тестов
8.3.2. Именование переменных
8.3.3. Утверждения со смыслом
8.3.4. Отделение утверждений от действий
8.3.5. Подготовка и очистка
8.4. Резюме
ЧАСТЬ 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. Используйте ЯеЭИагрегдля навигации и
рефакторинга продуктового кода
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. Дополнительные ресурсы
ПРИЛОЖЕНИЕ. Инструменты и каркасы
А. 1. Изолирующие каркасы
А.1.1. Moq
А. 1.2. Rhino Mocks
A. 1.3. Typemock Isolator
A. 1.4. JustMock
A. 1.5. Microsoft Fakes (Moles)
A. 1.6. NSubstitute
A. 1.7. FakeltEasy
A.1.8. Foq
A. 1.9. lsolator++
A.2. Каркасы тестирования
A.2.1. Непрерывный исполнитель тестов Mighty
Moose (он же ContinuousTests)
А.2.2. Непрерывный исполнитель тестов NCrunch
А.2.3. Исполнитель тестов Typemock Isolator
А.2.4. Исполнитель тестов CodeRush
А.2.5. Исполнитель тестов ReSharper
А.2.6. ИсполнительTestDriven.NET
А.2.7. Исполнитель NUnit GUI
А.2.8. Исполнитель MSTest
А.2.9. Рех
А.З. API тестирования
А.3.1. MSTest API - каркас автономного
тестирования от Мicrosoft
А.3.2. MSTest для приложений Metro (магазин
Windows)
А.3.3. NUnit API
А.З.4. xUnit.net
А.3.5. Вспомогательный API Fluent Assertions
А.3.6. Вспомогательный API Shouldly
А.3.7. Вспомогательный API SharpTestsEx
А.3.8. Вспомогательный API AutoFixture
А.4. loC-контейнеры
А.4.1. Autofac
А.4.2. Ninject
А.4.3. Castle Windsor
A.4.4. Microsoft Unity
A.4.5. StructureMap
A.4.6. Microsoft Managed Extensibility Framework
A.5. Тестирование работы с базами данных
А.5.1. Использование интеграционных тестов для
уровня данных
А.5.2. Использование TransactionScope для отката
изменений данных
А.6. Тестирование веб-приложений
А.6.1. Ivonna
А.6.2. Тестирование веб-приложений в Team System
А.6.3. Watir
А.6.4. Selenium WebDriver
А.6.5. Coypu
A.6.6. Capybara
А.6.7. Тестирование JavaScript
А.7. Тестирование пользовательского интерфейса
(персональных приложений)
А.8. Тестирование многопоточных приложений
А.8.1. Microsoft CHESS
А.8.2. Osherove.ThreadTester
А.9. Приемочное тестирование
А.9.1. FitNesse
А.9.2. SpecFlow
А.9.3. Cucumber
А.9.4. TickSpec
А. 10. Каркасы с API в стиле BDD
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ