Search
Write a publication
Pull to refresh

Comments 7

Здравствуйте, прочитал ваш материал, очень интересно. Понравилось пояснение - "компонентный тест - это частный случай интеграционного тестирования группы модулей". Исходя из вашего определения, что компонент состоит из модуля и является точкой входа, правильно ли я понимаю и описываю пример с методом-компонентом и методами-модулями?

Разделение на технические и бизнес данные сильно условно. Ключевая разница в изоляции кода (модульный) или функциональности (компонентный).

Расскажу о том, как у нас было на предпоследнем проекте:
Микросервисный продукт, есть е2е тестирование и unit-тесты(модульные, я привык модульными только unit-тесты называть, где в основном модулем является какой-то класс в коде продукта)
И поднялся вопрос - надо тестировать все правильно и красиво сразу, по пирамиде тестирования, пока еще мы контролируем ситуацию. И тк у нас есть верхний и нижний слой, то нужны интеграционные тесты. Те по факту нам нужно тестировать каждый компонент в отдельности (тут мы понимали компонент как сервис). Изолированно от других сервисов. И вроде по пирамиде нам нужны интеграционные тесты, а по делу - интеграцию мы тестируем на уровне е2е, а тут мы хотим отдельно сервисы тестировать изолированно, что б снизить объем е2е тестов.
И назвали такие тесты компонентными.
Те наша пирамида стала выглядеть вот так: юнит - компонентные - е2е
Я как бы понимаю, что пирамида может иметь больше уровней. Но на практике нам хватило этого.

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

Получается,что все это разделение субъективно и просто зависит от разбиения и абстракции, и больше всего размытости как раз на нижнем уровне. Недавно например мне высказали мнение,что ui тесты в определенном контексте тоже интеграционные - когда мы тестируем функционал ,который взаимодействует с сервером , форму например. Хотя вроде как , когда мы приступаем к ui это уже полноценное приложение (все его части собраны в единое) и тестирование системное.

В общем зависит от контекста и на собесах нужно не выпаливать определение,а рассуждать )

Да, полностью согласен, то же UI тестирование может быть:
компоненты - когда ответ от быка мотается и мы смотрим только работу фронта
интеграционным - когда мы смотрим работу фронта и определенного сервиса, но все зависимости мокаем
и системным - когда весь стенд работает как задумывалось изначально, без модов, стабов и прочих ухищрений

Sign up to leave a comment.

Articles