Это как сравнивать ложку с вилкой

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

совершенно не соглашусь. Тебе надо тратить время на них

а значит надо сравнивать: что принесет больше пользы

юнит тестирование гарантирует работу отдельно взтого модуля интеграция, прямо из названия кричит, что тестирует взаимодействие этих модулей. feature тесты один из способов интеграционного тестирования, и в принципе единственно возможный способ автоматизирования тестирования, которое способно гарантировать работу ВСЕЙ системы. Я не спорю, что можно интеграционным тестированием заменить модульное, но это займет больше времени, при сохранении качества, либо столько же - при потере качества. А значит это фенее эффективно

интеграционные гарантируют, что все оттестиованное работают для пользователя, а юнит нет )

и как бы пофиг что сыпется, если пользователь об этом не знает

Интеграционное тестирование - не всегда значит тестирования с проверкой UI

Можно прокрыть интерактор тестами и это тоже будет интеграционным тестированием - потому что проверит взаимодействие всех шагов интерактора

поэтому я выделил feature specs в отдельный абзац

+1

юнит тестирование гарантирует работу отдельно взтого модуля интеграция, прямо из названия кричит, что тестирует взаимодействие этих модулей. feature тесты один из способов интеграционного тестирования, и в принципе единственно возможный способ автоматизирования тестирования, которое способно гарантировать работу ВСЕЙ системы. Я не спорю, что можно интеграционным тестированием заменить модульное, но это займет больше времени, при сохранении качества, либо столько же - при потере качества. А значит это фенее эффективно

и вот безапелляционное мнение о том, что интеграционное тестирование занимает больше времени конечно же неверно =)

очень сильно зависит от задачи и от вариабельности API. Грубо говоря, если имплементишь чужое API, которое мало меняется, то интеграционные тесты скорее всего почти полностью могут заменить юнит, а если у тебя ядро примерно стабильно, но регулярно меняется то, что ты отдаешь людям, то будет наоборот

при прочих равных тестировать разными входынми данными модульно проще чем интеграционно

нет

это мнение само по себе не является правильным

Мы не спорим чье мнение правильно, а говорим о значении, если ты сможешь меня переубедить я буду только рад расширить кругозор

что бы протестировать модульно, тебе надо ОЧЕНЬ сильно заложиться на кишки приложения и в тесте реализовать всю ту логику, которая уже есть в твоём приложении что бы дотащить данные до твоего модуля

к тебе как-то приезжают данные. Что бы протестировать как они повлияют на кишки внутри софта, их надо распаковать

с интеграционным тестом ты можешь просто сделать HTTP вызов, а завтра поменять кишки с руби на какой-нибудь там Go и не менять тест

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

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

но между ними приходится выбирать

Дополняют - главное слово в сообщении

Никогда не возникало необходимости выбирать. Всегда исходил из того, что это лишь инструменты, гарантирующие качество кода и они друг друга дополняют, а не противоречат.

Ты не сможешь на лету подменить бек на GO с Ruby

Только если твой инструмент тестирования платформонезависимый

Но в этом случае это и будет только интеграционным тестированием

модульное же подразумевает работу исключительно с сущностями бекенда и такой трюк не прокатит

в итоге подисскутировали и пошли херачить код без тестов

в итоге подисскутировали и пошли херачить код без тестов

как ты узнал ?

Ты не сможешь на лету подменить бек на GO с Ruby

вот ты так думаешь, а я менял эрланг на питон =)

как ты узнал ?

слежу за тобой ?

в итоге подисскутировали и пошли херачить код без тестов

?

вот ты так думаешь, а я менял эрланг на питон =)

Звучит, конечно, круто :) Но я все равное не считаю что эти подходы являются взаимоисключающими

они конкурируют за время программиста

и между ними приходится искать баланс

ровно такой же баланс как между программированием и написанием тестов

у нас в CI такая картина:

version: v4.6.19-63-gfe390dc, failed/total: 0/2054 Total time: 1085s Compile time: 1s Init suite time: 68s End suite time: 0s Tests time: 1015s Tests total: 2054 Tests failed: 0 Tests skipped: 26 Tests ok: 2028

тут пропорция интеграционных к юнитам примерно 85/15

Acceptance test - тесты с позиции клиентка когда приложение black box integrational test - тест взаимодействия частей системы Ты разницу то расскажи

Первые - это а-ля копиюара, вторые - это когда запрос делаешь и там пара сервисов срабатывает без моков

вообще интересный вопрос про нейминг. Я тест когда-то на апворке проходил, у них получается, что юнит тест - это тест модели, функциональный - тест контроллера, интеграционный - целиком все

Что-то говноедство какое-тоня на эту тему отлично почитать фаулкра, он хорошо объясняет что и как

Парни, я вот до сих пор не вижу в рельсах вменяемых интеграционных тестов

Сделай тест на сохранение модели. Будет интеграционный ибо ты мало того, что колбэки будешь дергать, так ещё и валидации

Знаешь, есть такое мнение, что если не можешь объяснить нубу какое то понятие на пальцах, то до конца ты не понимаешь предмет.

Хочешь, я могу тебе объяснить ее, все равно в метро еду

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

это неправильно

правильно написать тест, как человек регистрируется, а оптом через фабрики создать несколько пользователей и протестировать как они общаются

а то, что ты говоришь - это отдать после автотестов в отдел тестирования, что бы там ручками прокликали и проверили

а то, что ты говоришь - это отдать после автотестов в отдел тестирования, что бы там ручками прокликали и проверили

то о чём я говорю — это вместо нанимания отдела тестирования потратить 10 минут и напрогать тест, который будет жить ооочень долго и проверять базовые функции системы после каждого коммита

и это правильно

отдел тестирования должен искать баги там, где их не могут найти программисты в силу своего склада ума и не успели найти пользователи. Заниматься повторяемой работой должны роботы

а то о чём ты говоришь — это не правильно/не правильно, а просто в рельсах только так и можно. Нет внятного способа тестировать рельсы как веб-сервер штатными средствами

а то о чём ты говоришь — это не правильно/не правильно, а просто в рельсах только так и можно. Нет внятного способа тестировать рельсы как веб-сервер штатными средствами

☝?

а то о чём ты говоришь — это не правильно/не правильно, а просто в рельсах только так и можно. Нет внятного способа тестировать рельсы как веб-сервер штатными средствами

есть, это капибара

браузер то не нужен для этого

ничего не мешает запустить два процесса капибары, что бы они работали вместе, но зачем?

Хочешь, я могу тебе объяснить ее, все равно в метро еду

Логика простая. Тесты логики, без внешних зависимостей (любых вообще, запросы в базу, на апи, вызов сторонних сервисов и так далее) - это юнит тест. Достаточно замокать все зависимости и тестировать только поведение конкретное. Это быстро и сами тесты быстрые + не надо генерировать кучу данных для теста Когда ты начинаешь тестировать ещё и зависимости внешние - это интеграционный тест. Например, ты трестируешь что эндпоинт возвращает правильное количество записей в базе и в правильной сортировке. Эти тесты проверяют связь между частями системы, одним тестом можно покрыть больше логики, но поддержка их дорогая очень + сами по себе они медленные End2end тесты - это когда ты прямо симулируешь поведение пользователя. Например, ты трестируешь мобильное приложение и поднимаешь тестовый апи для реальных запросов. Самые долгие тесты, очень сложно поддерживаемые, зато проверяют прямо все части системы на уровне восприятия юзера. Капибара тоже, в каком-то смысле подходит сюда

Логика простая. Тесты логики, без внешних зависимостей (любых вообще, запросы в базу, на апи, вызов сторонних сервисов и так далее) - это юнит тест. Достаточно замокать все зависимости и тестировать только поведение конкретное. Это быстро и сами тесты быстрые + не надо генерировать кучу данных для теста Когда ты начинаешь тестировать ещё и зависимости внешние - это интеграционный тест. Например, ты трестируешь что эндпоинт возвращает правильное количество записей в базе и в правильной сортировке. Эти тесты проверяют связь между частями системы, одним тестом можно покрыть больше логики, но поддержка их дорогая очень + сами по себе они медленные End2end тесты - это когда ты прямо симулируешь поведение пользователя. Например, ты трестируешь мобильное приложение и поднимаешь тестовый апи для реальных запросов. Самые долгие тесты, очень сложно поддерживаемые, зато проверяют прямо все части системы на уровне восприятия юзера. Капибара тоже, в каком-то смысле подходит сюда

вот как раз насчёт сложно поддерживаемых — это очень большой вопрос. Что ты называешь сложно поддерживаемым, если у тебя API меняется реже, чем внутренняя структура данных?

ничего не мешает запустить два процесса капибары, что бы они работали вместе, но зачем?

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

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

вот я и говорю, что такой тест не нужен

@maxlapshin мы говорим про интеграционное тестирование на разных уровнях. Ты про то, что выше Антон назвал End2End, насколько я понял. А я про отдельные сущности. Эти End2End я вынес в feature

но его можно сделать )

вот как раз насчёт сложно поддерживаемых — это очень большой вопрос. Что ты называешь сложно поддерживаемым, если у тебя API меняется реже, чем внутренняя структура данных?

У тебя поменялась внутренняя структура данных, тебе менять все данные для запуска теста

вот я и говорю, что такой тест не нужен

Ты не прав. Он нужен и полезен, но не как основной тест сьют

ну так я ровно об этом и писал выше: в тесте и зарегистрироваться

Ты не прав. Он нужен и полезен, но не как основной тест сьют

он очень долгий и не дает больше данных, чем юниты

ERROR: S client not available

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

он очень долгий и не дает больше данных, чем юниты

Ну так ещё раз, он не для частых прогонов

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

он очень долгий и не дает больше данных, чем юниты

дает. Высокоуровневый тест дает тебе картину по полному прохождению всех данных, включая какой-нибудь редис. Кто здесь пользуется редисом во время тестов?

а если в одном тесте две регистрации, отправки и получения, то это уже извращение какое то

зачем?

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

а если в одном тесте две регистрации, отправки и получения, то это уже извращение какое то

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

В итоге мы приходим к тому, что они друг друга дополняют и наивысшее качество продукта можно гарантированть только при наличии и того и другого.

А, проблема интеграционных тестов ещё в том, что если тестировать все возможные случаи - вы офигеете, количество результатов растёт очень не линейно

В итоге мы приходим к тому, что они друг друга дополняют и наивысшее качество продукта можно гарантированть только при наличии и того и другого.

Именно так

например ты в регистрации включил опцию делать человека readonly до подтверждения телефона, а в фабрике, которая тестирует отправку сообщения ты забыл это учесть

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

Он не живет очень долго. Ты поменяешь верстку и тесты пойдут по пизде

в итоге ты выкатываешь код на прод, который ты проверял не интеграционными а юнит тестами

Он не живет очень долго. Ты поменяешь верстку и тесты пойдут по пизде

Поэтому они и дороги в поддержке

Он не живет очень долго. Ты поменяешь верстку и тесты пойдут по пизде

верстку я уже не учитываю. Я всё таки говорю о данных, которые ты выплевываешь

верстка ставит крест на интеграционных тестах

верстку я уже не учитываю. Я всё таки говорю о данных, которые ты выплевываешь

Ну не

сразу, полный

Погоди ее

Ты говоришь про полное тестирование, как будешь без привязки к верстке это делать?

Вот тут и приходят проблемы

слушай, я уже не помню, когда я последний раз видел что-то, что отдает не json для реакта, а прям рендерит темплейт на сервере =)

Имя кнопки поменялось - обновляй тест

поэтому я именно в этом контексте рассуждаю

слушай, я уже не помню, когда я последний раз видел что-то, что отдает не json для реакта, а прям рендерит темплейт на сервере =)

Все сайты где надо в сео

угу

Гугл конечно умеет и JS, но увы, не только гугл поисковик

Ну собственно, я не против енд2енд, он даже полезен. Просто адекватно оценивай все риски, если писать только такие тесты

Тут конечно можно про серверный реакт упомянуть

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

отдел тестирования должен искать баги там, где их не могут найти программисты в силу своего склада ума и не успели найти пользователи. Заниматься повторяемой работой должны роботы

так у тестеров свои роботы есть(автотесты)