Что такое Fault Injection с картинками и примерами

Теория.

Практически всегда мы тестируем то как себя будет вести приложение при взаимодействии пользователя с ним.
Это правильно с одной стороны - пользователь важен, он приносит нам деньги и то "качество", которое хочет видеть пользователь - оно превыше всего.
Но есть определенные обстоятельства в которых мы тестируем не то как пользователь взаимодействует с приложением, а то как приложение взаимодействует с другими приложениями (если мы гооворим о распределенных системах) или как модули приложения взаимодействуют между собой.

(так выглядят сервисы внутри twitter, источник) 

И вот с этого момента нас начинает интересовать, что будет с нашим приложением А если приложение Б от которого оно зависит ляжет или начнет себя неадекватно вести.
Этим аспектам уделяют мало внимания, в лучшем случае - падение одного приложения потянет за собой крэш всей системы (пользовательской).
Это хорошо и правильно - если вы не видите для себя  другого способа, то пусть будет хотя бы так.

Однако если вы его не только видите но и используете, то скорее всего вы заинтересованы в проверке работоспособности вашей зашиты от падений сторонних компонентов.
И вот тут начинаются интересности:

1. Естественно у вас такая защита должна быть. А вот всунуть ее в legacy-код или продукт дизайн которого таких возможностей не предусматривал не так просто.
2. Уровень и с которого "падаем" и глубина падения. Если говорить про стандартную трехзвенную архитектуру, то тут фантазии особо разгуляться негде.
   Все намного интереснее  - често говоря просто эта задача актуальнее - когда у вас SOA или микросервисы. Здесь и уровней больше, типы и глубина падения тоже могут быть разными. Про типы хочется написать отдельно - это может быть как и просто генерация исключения для тестирования того что приложение стабильно его обрабатывает, проглатывает и снаружи ничего не видно, так и внедрение более изощеренного поведения - эмуляция неправильной конфигурации приложения, изменение диапазна типовых значений для экспериментов над поведением. Про банальности типа потери соединения с БД во время работы  - молчу.
3. Крушение приложения. Отдельная тема для распределенных систем особенно для тех что занимаются in-memory вычислениями (Storm, Kafka, Mesos, Suro). Что произойдет с блоком данных отправленным на in-memory обработку если обработчик сдох? Крушения опять же могут быть разными, но тут очень много специфики у каждого. 

Довольно теории, перейдем к практике.

Практика.

Для практики я построил на коленке простейшее вэб-приложение на Java (Jetty inside).
Приложение отзывается на три урла.
http://127.0.0.1:9090/doWork - отдает рандомное целое число от 0 до 1000.

http://127.0.0.1:9090/fault?mode=enabled - включает fault-режим
http://127.0.0.1:9090/fault?mode=disabled - выключает fault-режим

После включения режима падения генератор случайных числе начинает отдавать 0 или 1. Это и есть наше падение.
http://127.0.0.1:9090/crash?time=15 - падение приложения через  указанное время (опционально, если не указано, то упадет сразу).

Как оно организовано изнутри.

Внутри все сделал по максимуму просто - интерфейс генератора случайных чисел задекорирован и на уровне декоратора отрабатывает бизнес-логика использования или неиспользования fault-режима.

	public class GeneratorFaultDecorator implements RandomGenerator{
	private final FaultModeManager faultModeManager;
	private final RandomGenerator delegate;
	public GeneratorFaultDecorator(FaultModeManager faultModeManager, RandomGenerator delegate) {
	this.faultModeManager = faultModeManager;
	this.delegate = delegate;
	}
	@Override
	public int get() {
	if (faultModeManager.isEnabled()){
	return new Random().nextInt(2);
	}
	return delegate.get();
	}
	}

view raw gistfile1.java hosted with ❤ by GitHub

Код приложения выложен на github.

Хочется более приближенных к реальности примеров - их есть у меня.
Вот например ключи запуска Chromium

Книга: The "A" Word

Небезызвестный Alan Page (http://angryweasel.com/blog/angry-weasel/) систематизировал свои блог посты и издал книжку про автоматизацию на Lean Pub.

Мой коллега по цеху Максим Шульга опубликовал свой обзор этой книги, которая давно валялась в закоулках моего киндла.
Собственно обзор Макса (Привет, Макс:)) и дал мне пинка под зад, чтобы прочитать наконец-то эту книжку.

Я могу согласится с автором  во многом, но иногда материал излагается очень эмоционально.
В этой книжке написано о том к чему нужно стремится, но что не всегда и не везде достижимо.
Не нужно отчаиваться если что-то вокруг вас идет в разрез с тем что описывает автор - главное чтобы это не было вашим терминальным состоянием.

Что мне в книжке не понравилось так это то что любое приближение к практическим примерам сползает к фразам, которые часто упоминают Web или даже напрямую WebDriver. Задачи рассматриваются очень академически, реальность намного грубее и прозаичнее.

WebDriver - это конечно хорошо, но далеко не все, что есть в природе (и еще раз привет Максу и Ивану :) которые не дадут соврать, что это точно не все что есть в природе).

Это книга должна отрезвить тех тестировщиков и менеджеров, которые верят что автоматизация тестирования спасет тестирование на их проекте и им обязательно нужно автоматизировать что-нибудь.

Рекомендуется к прочтению, оценок не будет так как ни копейки я за нее не заплатил.