В чем смысл использовать тесты с моками вместо интеграционных тестов? При условии что интеграционные тесты возможны в данном случае, естественно.
Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает. Если ты написал тест с моками — может быть работает, может нет, хрен его знает.
Я чего-то не понимаю?
Здравствуйте, Codealot, Вы писали:
C>В чем смысл использовать тесты с моками вместо интеграционных тестов? При условии что интеграционные тесты возможны в данном случае, естественно. C>Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает. Если ты написал тест с моками — может быть работает, может нет, хрен его знает. C>Я чего-то не понимаю?
Безотносительно способа реализации (моки, стабы, фейки), есть три соображения: скорость работы тестов, сложность подготовки тестовых данных, параллелизация тестов
Здравствуйте, Codealot, Вы писали:
C>В чем смысл использовать тесты с моками вместо интеграционных тестов? При условии что интеграционные тесты возможны в данном случае, естественно. C>Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает.
Нет. Потому что
1) С реальным внешним компонентом ты не проверишь все возможные (предполагаемые) варианты ответа другого компонента. Часто их слишком сложно смоделировать с реальным компонентом.
2) Продолжение предыдущего — если компонент участвует некорректно. Например, что делать, если сервер ответил разрушенной структурой данных.
3) Могут быть взаимоскомпенсированные ошибки (см. фольклор про чётность числа багов). Они взорвутся позже, тогда, когда ты уже забыл, что это было, как и почему (или вообще не ты писал и тайное знание давно потеряно).
Здравствуйте, netch80, Вы писали:
N>Нет. Потому что N>1) С реальным внешним компонентом ты не проверишь все возможные (предполагаемые) варианты ответа другого компонента. Часто их слишком сложно смоделировать с реальным компонентом.
Да. Потому что ты абсолютно точно уверен, что те сценарии которые ты протестировал — реально работают. А в случае с моками ты всегда тестируешь частично реальный код, а частично — моки, в которых тоже могут быть ошибки или различия с реальным кодом.
N>2) Продолжение предыдущего — если компонент участвует некорректно. Например, что делать, если сервер ответил разрушенной структурой данных.
Значит, клиент поймает эту ошибку. Или выдаст некорректный результат, который будет пойман тестом.
Если же тест не проверят корректность конечных данных, то этот тест попросту говно.
N>3) Могут быть взаимоскомпенсированные ошибки (см. фольклор про чётность числа багов). Они взорвутся позже, тогда, когда ты уже забыл, что это было, как и почему (или вообще не ты писал и тайное знание давно потеряно).
Моки не дают никаких гарантий против этого, потому что могут быть взаимоскомпенсированные ошибки в самом моке. Или же все прекрасно работает с моком, но взрывается в реальном окружении, потому что его функционал отличается в какой-нибудь мелочи.
В общем и целом — использование моков может иметь некоторый смысл как дополнение интеграционных тестов, но ни в коем случае как их замена. См исходный вопрос.
Здравствуйте, Codealot, Вы писали:
C>В чем смысл использовать тесты с моками вместо интеграционных тестов? При условии что интеграционные тесты возможны в данном случае, естественно. C>Если ты написал интеграционные тесты — ты полностью уверен, что данный конкретный сценарий работает. Если ты написал тест с моками — может быть работает, может нет, хрен его знает. C>Я чего-то не понимаю?
Скорость выполнения. У меня интеграционный тест запускается секунд 10 (поднимается в докере БД, стартует спринг, создаётся схема, данные), далее каждый тест выполняется около 1 секунды.
С моками юнит-тест выполняется микросекунды. То бишь гораздо проще тестировать весь функционал в юнит-тестах. А функциональные тесты на самые основные сценарии, просто чтобы проверить, что ничего в целом не сломалось.
Здравствуйте, vsb, Вы писали:
vsb>Скорость выполнения. У меня интеграционный тест запускается секунд 10 (поднимается в докере БД, стартует спринг, создаётся схема, данные), далее каждый тест выполняется около 1 секунды.
vsb>С моками юнит-тест выполняется микросекунды. То бишь гораздо проще тестировать весь функционал в юнит-тестах. А функциональные тесты на самые основные сценарии, просто чтобы проверить, что ничего в целом не сломалось.
А затраты времени на создание моков и работу с усложненным кодом не учитываются?
Здравствуйте, Codealot, Вы писали:
N>>Нет. Потому что N>>1) С реальным внешним компонентом ты не проверишь все возможные (предполагаемые) варианты ответа другого компонента. Часто их слишком сложно смоделировать с реальным компонентом.
C>Да. Потому что ты абсолютно точно уверен, что те сценарии которые ты протестировал — реально работают.
Но ты не знаешь, _почему_ они работают. Чаще всего без покомпонентного тестирования это случайный успех, ничем не подтверждённый, который перестанет работать при малейшем отклонении от предполагаемых входных данных.
C> А в случае с моками ты всегда тестируешь частично реальный код, а частично — моки, в которых тоже могут быть ошибки или различия с реальным кодом.
Мок предельно примитивен по сравнению с реальным компонентом. Для большинства случаев это фигня, которая принимает запрос, сверяет его с эталоном в нужных местах и отдаёт фиксированный ответ. Чем проще мок, тем прямее тестирование. Такой простой мок покрывает >95% вариантов тестов (для большинства применений >99%).
N>>2) Продолжение предыдущего — если компонент участвует некорректно. Например, что делать, если сервер ответил разрушенной структурой данных. C>Значит, клиент поймает эту ошибку. Или выдаст некорректный результат, который будет пойман тестом.
Нет, он выдаст корректный, потому что просто заложен выдавать такое.
N>>3) Могут быть взаимоскомпенсированные ошибки (см. фольклор про чётность числа багов). Они взорвутся позже, тогда, когда ты уже забыл, что это было, как и почему (или вообще не ты писал и тайное знание давно потеряно).
C>Моки не дают никаких гарантий против этого, потому что могут быть взаимоскомпенсированные ошибки в самом моке. Или же все прекрасно работает с моком, но взрывается в реальном окружении, потому что его функционал отличается в какой-нибудь мелочи.
Повторюсь: мок делается предельно простым, чтобы вероятность ошибок в нём уменьшить до предела. Например, мок может на любой HTTP запрос отвечать фиксированным {'x':1, 'y':2}.
Посмотри на питоновский unittest.mock. Он не идеал (по-нормальному управляющие методы надо было бы вынести в отдельный объект), но на нём можно написать в духе
m = Mock()
m.foo.return_value = 44
и всё что надо — любой вызов m.foo() отдаст 44.
Зато в управляющем коде теста потом пишешь
Здравствуйте, Codealot, Вы писали:
vsb>>С моками юнит-тест выполняется микросекунды. То бишь гораздо проще тестировать весь функционал в юнит-тестах. А функциональные тесты на самые основные сценарии, просто чтобы проверить, что ничего в целом не сломалось.
C>А затраты времени на создание моков и работу с усложненным кодом не учитываются?
Затраты времени минимальны.
"Усложнённый код" — отчего бы? В каком домене такое?
Здравствуйте, Codealot, Вы писали:
C>Я чего-то не понимаю?
Моки — это тестирование алгоритмов внутри вашего собственного сервиса. То есть, как ваш код обрабатывает данные снаружи, здесь эти данные берутся из моков.
Другое дело, что если алгоритмов у вас в коде нет*, а есть одна сплошная интеграция, то и смысла в юнит-тестах нет, зато интеграционные тесты очень полезны.
*"...анализ бизнес-процессов показал, что бизнес-процессов по факту нет!" ((с) "Внедряй!", известный ролик на ютубе)
Здравствуйте, netch80, Вы писали:
N>Чаще всего без покомпонентного тестирования это случайный успех, ничем не подтверждённый, который перестанет работать при малейшем отклонении от предполагаемых входных данных.
Если в твоем коде такое происходит, то ты делаешь что-то очень сильно неправильно.
N>Мок предельно примитивен по сравнению с реальным компонентом. Для большинства случаев это фигня, которая принимает запрос, сверяет его с эталоном в нужных местах и отдаёт фиксированный ответ. Чем проще мок, тем прямее тестирование. Такой простой мок покрывает >95% вариантов тестов (для большинства применений >99%).
Такой код создает иллюзию для выполнения >95% вариантов тестов
N>Нет, он выдаст корректный, потому что просто заложен выдавать такое.
Щито? Клиент выдает то, что получил от сервера. То есть — некорректный результат.
N>Повторюсь: мок делается предельно простым, чтобы вероятность ошибок в нём уменьшить до предела. Например, мок может на любой HTTP запрос отвечать фиксированным {'x':1, 'y':2}.
Именно. А реальный код может выдать что-то куда сложнее. И что толку тогда от твоих моков?
N>Что может быть проще, прямолинейнее и понятнее?
Здравствуйте, netch80, Вы писали:
N>Затраты времени минимальны. N>"Усложнённый код" — отчего бы? В каком домене такое?
Ни хрена они не минимальны. Как минимум надо делать моки и следить за тем, чтобы обновлять их вместе с реальным кодом. Лишняя точка поломки.
Ну а если ты пишешь на C#/Java/тп, то придется еще городить лишние интерфейсы для классов.
Здравствуйте, Codealot, Вы писали:
vsb>>Скорость выполнения. У меня интеграционный тест запускается секунд 10 (поднимается в докере БД, стартует спринг, создаётся схема, данные), далее каждый тест выполняется около 1 секунды.
vsb>>С моками юнит-тест выполняется микросекунды. То бишь гораздо проще тестировать весь функционал в юнит-тестах. А функциональные тесты на самые основные сценарии, просто чтобы проверить, что ничего в целом не сломалось.
C>А затраты времени на создание моков и работу с усложненным кодом не учитываются?
Это ещё надо посмотреть, что сложней, создавать мок, который на нужные методы выплюнет нужный ответ или вставлять данные в БД, согласно схеме и констрейнтам.
С>>Моки — это тестирование алгоритмов внутри вашего собственного сервиса.
C>Чтобы тестировать алгоритмы (если они нормально спроектированы), никакие моки вообще не нужны.
думаю он имел ввиду тестирование как работает внутренняя логика при разных комбинациях на входе = параметры + значения возвращаемые моками.
да создание юнит-тестов может занять больше времени чем написание самой логики, но это делать надо обязательно
Здравствуйте, Codealot, Вы писали:
N>>Затраты времени минимальны. N>>"Усложнённый код" — отчего бы? В каком домене такое?
C>Ни хрена они не минимальны. Как минимум надо делать моки и следить за тем, чтобы обновлять их вместе с реальным кодом. Лишняя точка поломки. C>Ну а если ты пишешь на C#/Java/тп, то придется еще городить лишние интерфейсы для классов.
Не знаю, что там в C#. В Java Mockito прекрасно мокирует классы без всяких интерфейсов. И ничего делать не надо. У тебя кажется какой-то допотопный взгляд на моки, где надо интерфейс выделять, писать полноценную реализацию этого интерфейса, имитирующую реальный объект. Современные инструменты этого всего позволяют не делать.
// you can mock concrete classes, not only interfaces
LinkedList mockedList = mock(LinkedList.class);
// stubbing appears before the actual execution
when(mockedList.get(0)).thenReturn("first");
// the following prints "first"
System.out.println(mockedList.get(0));
// the following prints "null" because get(999) was not stubbed
System.out.println(mockedList.get(999));
Здравствуйте, vsb, Вы писали:
vsb>Не знаю, что там в C#. В Java Mockito прекрасно мокирует классы без всяких интерфейсов. И ничего делать не надо. У тебя кажется какой-то допотопный взгляд на моки, где надо интерфейс выделять, писать полноценную реализацию этого интерфейса, имитирующую реальный объект. Современные инструменты этого всего позволяют не делать.
По-моему, это особая магия в JVM, я не уверен, что CLR так умеет.
Здравствуйте, vsb, Вы писали:
vsb>У тебя кажется какой-то допотопный взгляд на моки, где надо интерфейс выделять
Не у меня, а у того, кто наколбасил проект, на который я прямо сейчас гляжу.
vsb>писать полноценную реализацию этого интерфейса, имитирующую реальный объект. Современные инструменты этого всего позволяют не делать.
Здравствуйте, Слава, Вы писали:
vsb>>Не знаю, что там в C#. В Java Mockito прекрасно мокирует классы без всяких интерфейсов. И ничего делать не надо. У тебя кажется какой-то допотопный взгляд на моки, где надо интерфейс выделять, писать полноценную реализацию этого интерфейса, имитирующую реальный объект. Современные инструменты этого всего позволяют не делать.
С>По-моему, это особая магия в JVM, я не уверен, что CLR так умеет.
Просто создаётся наследник класса, у него переопределяются все методы и всё. Ну магия там, конечно, есть, но для других вещей.
Здравствуйте, vsb, Вы писали:
С>>По-моему, это особая магия в JVM, я не уверен, что CLR так умеет.
vsb>Просто создаётся наследник класса, у него переопределяются все методы и всё. Ну магия там, конечно, есть, но для других вещей.
Так если методы не виртуальные, то вызываться будут методы предка.
