Почитываю книжку Искусство Agile-тестирования и наткнулся в ней на такую штуку как "компонентное тестирование". В книге довольно размытое описание, и начав читать об этом виде тестирования, я понял, что для меня не все так очевидно.

Всем привет! Относительно недавно, мне повезло столкнуться с задачей автоматизации, связанной с шиной событий EventBus. Задача довольно интересная, поэтому хочу поделиться своим решением, вдруг помогу кому-нибудь)

При изучении техники тест-дизайна “доменный анализ”, я столкнулся с тем, что многие авторы описывают ее по-своему, что вполне логично. Перелопатить много разных статей об одном и том же, чтобы найти подходящее изложение материала и в конце концов понять желаемое - естественный процесс обучения. Но в случае доменного анализа, я заметил расхождение: кто-то описывает данную технику сложно, а кто-то ограничивается простой позицией - “это просто работа с классами эквивалентности и граничными значениями”.

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

Так вот, сценарии использования и альтернативные сценарии, мы обычно получаем от аналитиков из спецификации.. таблицы, деревья и диаграммы мало кто чертит, так как это занимает много времени (при дефиците ресурсов). Как правило, в ходу две популярные техники: классы эквивалентности и граничные значения, и только отдельные умнички используют pairwise ( попарное тестирование ).