Здравствуйте, Aquilaware, Вы писали:
A>Теперь, чтобы протестировать все эти алгоритмы интеграционными тестами понадобится M * N * L тестов, что очень много.
Зачем? Тестируй только те комбинации сценариев для каждого слоя, которые тебе нужны. Если твоя бизнес-логика работает корректно с одной базой данных, то тестировать ее подробно для всех остальных баз данных не имеет большого смысла. Это в качестве примера.
A>Но если слои тестировать отдельно, как бы изолируя их друг от друга, то понадобится всего лишь M + N + L тестов чтобы полностью покрыть все алгоритмы проекта.
То есть ты решил вообще не тестировать разные комбинации сценариев и тебе показалось, что ты потестировал все. Не, это так не работает.
Кроме того, ты уклонился от вопроса. Какова мотивация вообще не делать интеграционные тесты?
Здравствуйте, baxton_ulf, Вы писали:
_>этот что-ли "Расскажи мне что за клиент..."? _>в моем понимании так быть не должно если в клиенте нет багов. вот что-бы их найти и нужен мок сервера
Да-да, этот. Только ты опять написал бессвязицу.
_>хе хе, начал огрызаться в ответ. релакс бро
_>что именно не понятно? есть (должен быть) контракт между клиентом и сервером. в своем коде ты вправе ожидать соблюдения этого контракта == спокойно написать мок сервера, который возвращает корректные данные
Ну а когда контракт поменяли, то все моки сами автоматически все обновят. Да же?
Здравствуйте, Codealot, Вы писали:
_>>что именно не понятно? есть (должен быть) контракт между клиентом и сервером. в своем коде ты вправе ожидать соблюдения этого контракта == спокойно написать мок сервера, который возвращает корректные данные
C>Ну а когда контракт поменяли, то все моки сами автоматически все обновят. Да же?
это еще почему? ручками будешь править, как еще? и время на это должно быть запланировано и никакого сарказма
Здравствуйте, Codealot, Вы писали:
C>Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает. Если ты написал тест с моками — может быть работает, может нет, хрен его знает. C>Я чего-то не понимаю?
А какой code coverage у интеграционных тестов, branch coverage?
Здравствуйте, Codealot, Вы писали:
S>>А какой code coverage у интеграционных тестов, branch coverage? C>А какое это имеет отношение к заданному мной вопросу?
Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает.
Откуда такая уверенность? Какой процент кода хотя бы выполняется? Может какой-то if не учтен?
Здравствуйте, Sharov, Вы писали:
S>Откуда такая уверенность? Какой процент кода хотя бы выполняется? Может какой-то if не учтен?
Оттуда, что код который выполняется во время теста и выдает корректные результаты — работает.
Но ты опять уклоняешься от вопроса. Ключевое слово — вместо.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
S>>Откуда такая уверенность? Какой процент кода хотя бы выполняется? Может какой-то if не учтен?
C>Оттуда, что код который выполняется во время теста и выдает корректные результаты — работает. C>Но ты опять уклоняешься от вопроса. Ключевое слово — вместо.
да почему же вместо? нужны и те и те. только юнит-тесты (с моками ) позволяют покрыть 100% твоего кода.
тот факт, что в твоем проекте нет интеграционных тестов означает, что его писали люди не слишком высокой квалификации. они не утруждали себя вопросом как гарантировать корректность всего кода при внесении туда изменений или при изменениях в зависимостях. возможно они целиком полагались на QA команду.
Здравствуйте, Codealot, Вы писали:
S>>Откуда такая уверенность? Какой процент кода хотя бы выполняется? Может какой-то if не учтен? C>Оттуда, что код который выполняется во время теста и выдает корректные результаты — работает. C>Но ты опять уклоняешься от вопроса. Ключевое слово — вместо.
Вместо может и не надо. Скажем так, при ограниченных ресурсах и времени я бы предпочел интеграционные тесты --
меньше подвержены изменениям, реально тестируют взаимодействие с др. сервисами. Но качество покрытия кода будет
скорее всего небольшим.
Вот хорошая статья (https://martinfowler.com/articles/practical-test-pyramid.html),
которую я пока сам не осилил, вот цитата оттуда:
1)Write tests with different granularity
2)The more high-level you get the fewer tests you should have
Авторы рекомендуют иметь не очень много интеграционных тестов, по сравнению с юнит, что автоматом
влечет более низкое покрытие.
Но во варианте или-или я бы выбрал интеграционные, конечно. Минимальный показатель, что хоть что-то
работает. Но это не скажет о качестве кода практически ничего.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, baxton_ulf, Вы писали:
_>>да почему же вместо? нужны и те и те. только юнит-тесты (с моками ) позволяют покрыть 100% твоего кода.
C>Потому что многие делают именно вместо, вот почему
может ты просто чего-то не заметил / не знаешь? (просто предположение, никаких наездов )
например в моей предыдущей команде интеграционные тесты писали сами программисты, а в текущей это обязанность QA команды. и где они там у них хранятся лично я не имею понятия
Здравствуйте, Codealot, Вы писали:
C>В чем смысл использовать тесты с моками вместо интеграционных тестов? При условии что интеграционные тесты возможны в данном случае, естественно.
Использование моков не противоречит концепции итреграционных тестов. Ты вполне можешь написать интеграционные тесты для системы где часть компонентов заменена моками.
C>Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает. Если ты написал тест с моками — может быть работает, может нет, хрен его знает.
Причин на использование моков очень много. Наверное самая очевидная причина это размер проекта и сферы ответственности команд. Если проект достаточно крупный, то сделать интеграционный тест для всей системы может не быть возможным, т.к. надо слишком много данных и симуляций, в то время как моки позволяют сильно сузит объем тестирования. Вторая причина — это возможность зафиксировать конкретное поведение и отслеживать регрессии. Если тестируется система целиком, то регрессия может быть не заметной, т.к. функционал системы (ещё/временно) не используется или используется не правильно.
Здравствуйте, Codealot, Вы писали:
C>В чем смысл использовать тесты с моками вместо интеграционных тестов? При условии что интеграционные тесты возможны в данном случае, естественно. C>Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает. Если ты написал тест с моками — может быть работает, может нет, хрен его знает. C>Я чего-то не понимаю?
Здравствуйте, Codealot, Вы писали:
N>>Подход "или-или" я не приемлю с самого начала, он деструктивен. C>Это не ко мне вопрос. Вот прямо сейчас я гляжу на проект, в котором есть тесты с моками и нет ни одного интеграционного теста. И это не в первый раз.
Ну если подходить именно через "или-или"... вот на текущем проекте есть N компонент. Они разрабатываются по единому плану (например, общее управление конфигурацией). Но при этом есть межвендорские стандарты на взаимодействие, по которым вместо каждого из компонентов можно подставить чужой, если он выполняет все необходимые требования стандартов.
Как по-твоему их лучше тестировать — делать общие интеграционные тесты или таки по частям, каждый отдельно, со своими моками? Я буду толкать в первую очередь именно второй вариант.
N>>Это не определение сценария, в том и проблема.
C>Для данного случая, тесты с моками не имеют никаких плюсов перед прочими тестами. Собственно, все.
Имеют. Если ты проверяешь только во взаимодействии, ты не знаешь, что происходит внутри. Там могут быть любые отклонения от предполагаемого интерфейса взаимодействия.
Но если ты тестируешь каждый компонент сам по себе, то
1) У тебя определены интерфейсы, которые они должны соблюдать.
2) При любой проблеме ты можешь воспрозведением бага у себя проверить это взаимодействие, определить конкретные данные, при которых происходит проблема, снять точный обмен данными, сделать его повторяемым для воспроизведения бага в конкретном компоненте и для последующего автотеста на этот случай.
Как известно, каждая локализация бага или теста на уровень ниже уменьшает стоимость лечения и тестирования в несколько раз. Так что — сплошная польза.
Здравствуйте, Codealot, Вы писали:
A>>Теперь, чтобы протестировать все эти алгоритмы интеграционными тестами понадобится M * N * L тестов, что очень много.
C>Зачем? Тестируй только те комбинации сценариев для каждого слоя, которые тебе нужны.
Затем, что ты никогда не предугадаешь, как твой софт будут использовать у клиентов. Часто это оказывается такой вариант, который вообще не соответствует предполагаемой начальной цели.
C> Если твоя бизнес-логика работает корректно с одной базой данных, то тестировать ее подробно для всех остальных баз данных не имеет большого смысла. Это в качестве примера.
Если твоя бизнес-логика "работает корректно с одной базой данных", то ты остальные просто не поддерживаешь.
C>Кроме того, ты уклонился от вопроса. Какова мотивация вообще не делать интеграционные тесты?
Я понимаю, что тут типа КСВ, но заведомо обструктивная постановка вопроса скучна.
Здравствуйте, Sharov, Вы писали:
S>А какой code coverage у интеграционных тестов, branch coverage?
Happy path покрыт, а больше в общем-то и не надо. Уж если оно не работает — значит ничего не работает, а если оно работает — значит и проектом можно пользоваться, если не заниматься ерундой.
Здравствуйте, Codealot, Вы писали:
C>То есть ты решил вообще не тестировать разные комбинации сценариев и тебе показалось, что ты потестировал все. Не, это так не работает.
Вы заблуждаетесь. Я как раз решил ультимативно протестировать все комбинации используя всего 30 наборов тестов (при условии что M = N = L = 10), т. е. по одному для каждого алгоритма.
А вы же решили, сделать 1000 интеграционных тестов. Ваше право.
Здравствуйте, Слава, Вы писали:
С>Happy path покрыт, а больше в общем-то и не надо. Уж если оно не работает — значит ничего не работает, а если оно работает — значит и проектом можно пользоваться, если не заниматься ерундой.
Я недавно приводил пример, когда happy path у архиватора Ain работал, но когда ему подсунули большой датасет, то полученный архив (свой же!) он распаковать не смог — алгоритм ожидал выделить слишком много памяти. Вот такой сценарий вплоне можно покрыть моками через генерацию соответствующего data stream:
стандартный архив
битый архив
архив большого размера
архив с большим количеством мелких элементов
архив с большим уровнем вложенности папок
если есть защита паролями/пермиссиями — проверяем negative testing
) позволяют покрыть 100% твоего кода.
