#моки — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #моки, aggregated by home.social.
-
Моки без боли
Моки — достаточно крутой инструмент, если использовать его правильно. И все-таки лично для меня писать и поддерживать тесты на моках всегда было отдельным видом боли. Думаю, все знакомы с ситуацией: добавил в метод новый аргумент — и пошёл в 30 тест-кейсов проставлять заглушки. И это только от одного нового аргумента. И я не буду здесь спорить о терминологии — в этой статье я буду называть все тестовые дублёры «моками». Примеры будут на Scala, но моки в других языках работают похожим образом, так что боль универсальная. Как и решение — об этом в статье.
https://habr.com/ru/articles/1030834/
#scala #scalamock #zio #catseffect #тестирование #моки #стабы #моктестирование #юниттестирование
-
Моки без боли
Моки — достаточно крутой инструмент, если использовать его правильно. И все-таки лично для меня писать и поддерживать тесты на моках всегда было отдельным видом боли. Думаю, все знакомы с ситуацией: добавил в метод новый аргумент — и пошёл в 30 тест-кейсов проставлять заглушки. И это только от одного нового аргумента. И я не буду здесь спорить о терминологии — в этой статье я буду называть все тестовые дублёры «моками». Примеры будут на Scala, но моки в других языках работают похожим образом, так что боль универсальная. Как и решение — об этом в статье.
https://habr.com/ru/articles/1030834/
#scala #scalamock #zio #catseffect #тестирование #моки #стабы #моктестирование #юниттестирование
-
Моки без боли
Моки — достаточно крутой инструмент, если использовать его правильно. И все-таки лично для меня писать и поддерживать тесты на моках всегда было отдельным видом боли. Думаю, все знакомы с ситуацией: добавил в метод новый аргумент — и пошёл в 30 тест-кейсов проставлять заглушки. И это только от одного нового аргумента. И я не буду здесь спорить о терминологии — в этой статье я буду называть все тестовые дублёры «моками». Примеры будут на Scala, но моки в других языках работают похожим образом, так что боль универсальная. Как и решение — об этом в статье.
https://habr.com/ru/articles/1030834/
#scala #scalamock #zio #catseffect #тестирование #моки #стабы #моктестирование #юниттестирование
-
Моки без боли
Моки — достаточно крутой инструмент, если использовать его правильно. И все-таки лично для меня писать и поддерживать тесты на моках всегда было отдельным видом боли. Думаю, все знакомы с ситуацией: добавил в метод новый аргумент — и пошёл в 30 тест-кейсов проставлять заглушки. И это только от одного нового аргумента. И я не буду здесь спорить о терминологии — в этой статье я буду называть все тестовые дублёры «моками». Примеры будут на Scala, но моки в других языках работают похожим образом, так что боль универсальная. Как и решение — об этом в статье.
https://habr.com/ru/articles/1030834/
#scala #scalamock #zio #catseffect #тестирование #моки #стабы #моктестирование #юниттестирование
-
Пишем быстрые UI-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство UI-тестов флакают, медленно работают и в итоге отключаются в CI. Показываю альтернативу — изоляционные UI-тесты без стендов, таймингов и боли.
https://habr.com/ru/articles/982296/
#python #ui #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
Пишем быстрые UI-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство UI-тестов флакают, медленно работают и в итоге отключаются в CI. Показываю альтернативу — изоляционные UI-тесты без стендов, таймингов и боли.
https://habr.com/ru/articles/982296/
#python #ui #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
Пишем быстрые UI-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство UI-тестов флакают, медленно работают и в итоге отключаются в CI. Показываю альтернативу — изоляционные UI-тесты без стендов, таймингов и боли.
https://habr.com/ru/articles/982296/
#python #ui #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
Пишем быстрые UI-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство UI-тестов флакают, медленно работают и в итоге отключаются в CI. Показываю альтернативу — изоляционные UI-тесты без стендов, таймингов и боли.
https://habr.com/ru/articles/982296/
#python #ui #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
Пишем быстрые API-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство API-тестов бесполезны: они флакают и тормозят CI. Показываю альтернативу — изоляционные тесты без стендов и боли.
https://habr.com/ru/articles/978660/
#python #api #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
Пишем быстрые API-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство API-тестов бесполезны: они флакают и тормозят CI. Показываю альтернативу — изоляционные тесты без стендов и боли.
https://habr.com/ru/articles/978660/
#python #api #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
Пишем быстрые API-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство API-тестов бесполезны: они флакают и тормозят CI. Показываю альтернативу — изоляционные тесты без стендов и боли.
https://habr.com/ru/articles/978660/
#python #api #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
Пишем быстрые API-автотесты без флаков, стендов и боли: изоляционный подход в CI/CD
Большинство API-тестов бесполезны: они флакают и тормозят CI. Показываю альтернативу — изоляционные тесты без стендов и боли.
https://habr.com/ru/articles/978660/
#python #api #qa #qa_automation #автотесты #docker #cicd #mock #моки #мокирование
-
ZIO Mock не может — ScalaMock поможет
Если вы пишете тесты на ZIO, то с моками, скорее всего, уже сталкивались. И почти наверняка — с ZIO Mock. Формально он решает задачу, но на практике ломает Arrange‑Act‑Assert, «краснит» в IDEA и иногда падает так, что вы видите только InvalidCallException: null. В Яндекс Вертикалях мы довольно долго жили с этой библиотекой — пока количество таких тестов не перевалило за пару сотен и они не расползлись по десятку команд. Меня зовут Женя Веретенников, я тимлид в Яндекс Вертикалях и последние годы занимаюсь инструментами для Scala‑разработчиков и инфраструктурой бэкенд‑монорепозитория. Когда стало ясно, что ZIO Mock больше мешает, чем помогает, мы решили отказаться от него полностью — и подружить ZIO Test с классическим ScalaMock. Он даёт более предсказуемый синтаксис и понятные ошибки, но из коробки с ZIO не работает. В этой статье я расскажу не о том, как пользоваться новой библиотекой, а о том, как мы её делали: какие ограничения ZIO‑стека пришлось учитывать, где пришлось лезть под капот ScalaMock и ZIO Test и во что в итоге превратилась эта инженерная затея. Это история про построение собственного test tooling в большой Scala‑кодовой базе — с честными компромиссами и практическими выводами.
-
ZIO Mock не может — ScalaMock поможет
Если вы пишете тесты на ZIO, то с моками, скорее всего, уже сталкивались. И почти наверняка — с ZIO Mock. Формально он решает задачу, но на практике ломает Arrange‑Act‑Assert, «краснит» в IDEA и иногда падает так, что вы видите только InvalidCallException: null. В Яндекс Вертикалях мы довольно долго жили с этой библиотекой — пока количество таких тестов не перевалило за пару сотен и они не расползлись по десятку команд. Меня зовут Женя Веретенников, я тимлид в Яндекс Вертикалях и последние годы занимаюсь инструментами для Scala‑разработчиков и инфраструктурой бэкенд‑монорепозитория. Когда стало ясно, что ZIO Mock больше мешает, чем помогает, мы решили отказаться от него полностью — и подружить ZIO Test с классическим ScalaMock. Он даёт более предсказуемый синтаксис и понятные ошибки, но из коробки с ZIO не работает. В этой статье я расскажу не о том, как пользоваться новой библиотекой, а о том, как мы её делали: какие ограничения ZIO‑стека пришлось учитывать, где пришлось лезть под капот ScalaMock и ZIO Test и во что в итоге превратилась эта инженерная затея. Это история про построение собственного test tooling в большой Scala‑кодовой базе — с честными компромиссами и практическими выводами.
-
ZIO Mock не может — ScalaMock поможет
Если вы пишете тесты на ZIO, то с моками, скорее всего, уже сталкивались. И почти наверняка — с ZIO Mock. Формально он решает задачу, но на практике ломает Arrange‑Act‑Assert, «краснит» в IDEA и иногда падает так, что вы видите только InvalidCallException: null. В Яндекс Вертикалях мы довольно долго жили с этой библиотекой — пока количество таких тестов не перевалило за пару сотен и они не расползлись по десятку команд. Меня зовут Женя Веретенников, я тимлид в Яндекс Вертикалях и последние годы занимаюсь инструментами для Scala‑разработчиков и инфраструктурой бэкенд‑монорепозитория. Когда стало ясно, что ZIO Mock больше мешает, чем помогает, мы решили отказаться от него полностью — и подружить ZIO Test с классическим ScalaMock. Он даёт более предсказуемый синтаксис и понятные ошибки, но из коробки с ZIO не работает. В этой статье я расскажу не о том, как пользоваться новой библиотекой, а о том, как мы её делали: какие ограничения ZIO‑стека пришлось учитывать, где пришлось лезть под капот ScalaMock и ZIO Test и во что в итоге превратилась эта инженерная затея. Это история про построение собственного test tooling в большой Scala‑кодовой базе — с честными компромиссами и практическими выводами.
-
ZIO Mock не может — ScalaMock поможет
Если вы пишете тесты на ZIO, то с моками, скорее всего, уже сталкивались. И почти наверняка — с ZIO Mock. Формально он решает задачу, но на практике ломает Arrange‑Act‑Assert, «краснит» в IDEA и иногда падает так, что вы видите только InvalidCallException: null. В Яндекс Вертикалях мы довольно долго жили с этой библиотекой — пока количество таких тестов не перевалило за пару сотен и они не расползлись по десятку команд. Меня зовут Женя Веретенников, я тимлид в Яндекс Вертикалях и последние годы занимаюсь инструментами для Scala‑разработчиков и инфраструктурой бэкенд‑монорепозитория. Когда стало ясно, что ZIO Mock больше мешает, чем помогает, мы решили отказаться от него полностью — и подружить ZIO Test с классическим ScalaMock. Он даёт более предсказуемый синтаксис и понятные ошибки, но из коробки с ZIO не работает. В этой статье я расскажу не о том, как пользоваться новой библиотекой, а о том, как мы её делали: какие ограничения ZIO‑стека пришлось учитывать, где пришлось лезть под капот ScalaMock и ZIO Test и во что в итоге превратилась эта инженерная затея. Это история про построение собственного test tooling в большой Scala‑кодовой базе — с честными компромиссами и практическими выводами.
-
Proxyman + HAR = mock-данные для iOS-тестов
В Naumen мы используем связку Proxyman + HAR , чтобы готовить mock-данные для интеграционных тестов iOS-приложений. Такой подход выручает, когда реальный сервер недоступен или не умеет переводить себя в нужное состояние для проверки: мы перехватываем сетевой трафик приложения, сохраняем его и превращаем в готовые моки. О том, как именно мы это делаем, рассказывает Ринат, iOS-разработчик Naumen. В его практике Proxyman помогает быстро собирать сетевые сценарии, а экспорт в HAR и консольная утилита позволяют автоматически преобразовывать их в моки для тестов. Это экономит часы ручной работы и делает интеграционные тесты стабильными и предсказуемыми.
https://habr.com/ru/companies/naumen/articles/953168/
#iOS #Swift #Proxyman #HAR #моки #тестирование_мобильных_приложений #URLProtocol #автоматизация_тестирования #mobile_qa
-
Proxyman + HAR = mock-данные для iOS-тестов
В Naumen мы используем связку Proxyman + HAR , чтобы готовить mock-данные для интеграционных тестов iOS-приложений. Такой подход выручает, когда реальный сервер недоступен или не умеет переводить себя в нужное состояние для проверки: мы перехватываем сетевой трафик приложения, сохраняем его и превращаем в готовые моки. О том, как именно мы это делаем, рассказывает Ринат, iOS-разработчик Naumen. В его практике Proxyman помогает быстро собирать сетевые сценарии, а экспорт в HAR и консольная утилита позволяют автоматически преобразовывать их в моки для тестов. Это экономит часы ручной работы и делает интеграционные тесты стабильными и предсказуемыми.
https://habr.com/ru/companies/naumen/articles/953168/
#iOS #Swift #Proxyman #HAR #моки #тестирование_мобильных_приложений #URLProtocol #автоматизация_тестирования #mobile_qa
-
Proxyman + HAR = mock-данные для iOS-тестов
В Naumen мы используем связку Proxyman + HAR , чтобы готовить mock-данные для интеграционных тестов iOS-приложений. Такой подход выручает, когда реальный сервер недоступен или не умеет переводить себя в нужное состояние для проверки: мы перехватываем сетевой трафик приложения, сохраняем его и превращаем в готовые моки. О том, как именно мы это делаем, рассказывает Ринат, iOS-разработчик Naumen. В его практике Proxyman помогает быстро собирать сетевые сценарии, а экспорт в HAR и консольная утилита позволяют автоматически преобразовывать их в моки для тестов. Это экономит часы ручной работы и делает интеграционные тесты стабильными и предсказуемыми.
https://habr.com/ru/companies/naumen/articles/953168/
#iOS #Swift #Proxyman #HAR #моки #тестирование_мобильных_приложений #URLProtocol #автоматизация_тестирования #mobile_qa
-
Proxyman + HAR = mock-данные для iOS-тестов
В Naumen мы используем связку Proxyman + HAR , чтобы готовить mock-данные для интеграционных тестов iOS-приложений. Такой подход выручает, когда реальный сервер недоступен или не умеет переводить себя в нужное состояние для проверки: мы перехватываем сетевой трафик приложения, сохраняем его и превращаем в готовые моки. О том, как именно мы это делаем, рассказывает Ринат, iOS-разработчик Naumen. В его практике Proxyman помогает быстро собирать сетевые сценарии, а экспорт в HAR и консольная утилита позволяют автоматически преобразовывать их в моки для тестов. Это экономит часы ручной работы и делает интеграционные тесты стабильными и предсказуемыми.
https://habr.com/ru/companies/naumen/articles/953168/
#iOS #Swift #Proxyman #HAR #моки #тестирование_мобильных_приложений #URLProtocol #автоматизация_тестирования #mobile_qa
-
Monkey patching? В Go? Серьёзно? Или ка писать тесты и не сойти сума
На днях подходит ко мне коллега с вопросом: «Слушай, а как в Go сделать замену логики функции в тесте?» Я уточняю, что он имеет в виду. А он такой: «Ну, хочу monkey patching, чтобы подменять функции из коробки. Типа time.Now возвращала фиксированное время, uuid.New конкретный ID. Чтобы удобно тестироваться». И тут я, конечно, немного завис :D Да, технически в Go есть способы делать monkey patching (еще и есть библиотека ) через unsafe, через подмену указателей на функции в рантайме. Но это настолько хрупкое и непредсказуемое решение, что я бы не советовал тащить его в продакшен-код. Особенно когда есть нормальный, идиоматичный способ решить эту задачу.
-
Monkey patching? В Go? Серьёзно? Или ка писать тесты и не сойти сума
На днях подходит ко мне коллега с вопросом: «Слушай, а как в Go сделать замену логики функции в тесте?» Я уточняю, что он имеет в виду. А он такой: «Ну, хочу monkey patching, чтобы подменять функции из коробки. Типа time.Now возвращала фиксированное время, uuid.New конкретный ID. Чтобы удобно тестироваться». И тут я, конечно, немного завис :D Да, технически в Go есть способы делать monkey patching (еще и есть библиотека ) через unsafe, через подмену указателей на функции в рантайме. Но это настолько хрупкое и непредсказуемое решение, что я бы не советовал тащить его в продакшен-код. Особенно когда есть нормальный, идиоматичный способ решить эту задачу.
-
Monkey patching? В Go? Серьёзно? Или ка писать тесты и не сойти сума
На днях подходит ко мне коллега с вопросом: «Слушай, а как в Go сделать замену логики функции в тесте?» Я уточняю, что он имеет в виду. А он такой: «Ну, хочу monkey patching, чтобы подменять функции из коробки. Типа time.Now возвращала фиксированное время, uuid.New конкретный ID. Чтобы удобно тестироваться». И тут я, конечно, немного завис :D Да, технически в Go есть способы делать monkey patching (еще и есть библиотека ) через unsafe, через подмену указателей на функции в рантайме. Но это настолько хрупкое и непредсказуемое решение, что я бы не советовал тащить его в продакшен-код. Особенно когда есть нормальный, идиоматичный способ решить эту задачу.
-
Monkey patching? В Go? Серьёзно? Или ка писать тесты и не сойти сума
На днях подходит ко мне коллега с вопросом: «Слушай, а как в Go сделать замену логики функции в тесте?» Я уточняю, что он имеет в виду. А он такой: «Ну, хочу monkey patching, чтобы подменять функции из коробки. Типа time.Now возвращала фиксированное время, uuid.New конкретный ID. Чтобы удобно тестироваться». И тут я, конечно, немного завис :D Да, технически в Go есть способы делать monkey patching (еще и есть библиотека ) через unsafe, через подмену указателей на функции в рантайме. Но это настолько хрупкое и непредсказуемое решение, что я бы не советовал тащить его в продакшен-код. Особенно когда есть нормальный, идиоматичный способ решить эту задачу.
-
Фронтенд обгоняет бек или как мы написали 200_000 строк кода на моках
Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4. В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте. Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,
https://habr.com/ru/articles/970606/
#интеграция_на_фронтенде #typescript #javascript #ошибки_при_интеграции_на_фронтенде #ts #моки #мокирование #мокирование_при_интеграции #проблемы_при_интеграции_на_моках
-
Фронтенд обгоняет бек или как мы написали 200_000 строк кода на моках
Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4. В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте. Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,
https://habr.com/ru/articles/970606/
#интеграция_на_фронтенде #typescript #javascript #ошибки_при_интеграции_на_фронтенде #ts #моки #мокирование #мокирование_при_интеграции #проблемы_при_интеграции_на_моках
-
Фронтенд обгоняет бек или как мы написали 200_000 строк кода на моках
Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4. В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте. Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,
https://habr.com/ru/articles/970606/
#интеграция_на_фронтенде #typescript #javascript #ошибки_при_интеграции_на_фронтенде #ts #моки #мокирование #мокирование_при_интеграции #проблемы_при_интеграции_на_моках
-
Фронтенд обгоняет бек или как мы написали 200_000 строк кода на моках
Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4. В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте. Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,
https://habr.com/ru/articles/970606/
#интеграция_на_фронтенде #typescript #javascript #ошибки_при_интеграции_на_фронтенде #ts #моки #мокирование #мокирование_при_интеграции #проблемы_при_интеграции_на_моках
-
Лучшие практики автоматизации тестирования: 9 принципов стабильных автотестов
Почему автотесты становятся нестабильными и перестают приносить пользу? Разбираем системные причины флаков, бессмысленных ретраев и бесконечных E2E-монстров. Практические принципы: моки, изоляция, атомарность и минимализм — без философии, только инженерия.
https://habr.com/ru/articles/965890/
#автотесты #qa #qa_automation #python #golang #автоматизация_тестирования #лучшие_практики #моки #рефакторинг #flakyтесты
-
Лучшие практики автоматизации тестирования: 9 принципов стабильных автотестов
Почему автотесты становятся нестабильными и перестают приносить пользу? Разбираем системные причины флаков, бессмысленных ретраев и бесконечных E2E-монстров. Практические принципы: моки, изоляция, атомарность и минимализм — без философии, только инженерия.
https://habr.com/ru/articles/965890/
#автотесты #qa #qa_automation #python #golang #автоматизация_тестирования #лучшие_практики #моки #рефакторинг #flakyтесты
-
Лучшие практики автоматизации тестирования: 9 принципов стабильных автотестов
Почему автотесты становятся нестабильными и перестают приносить пользу? Разбираем системные причины флаков, бессмысленных ретраев и бесконечных E2E-монстров. Практические принципы: моки, изоляция, атомарность и минимализм — без философии, только инженерия.
https://habr.com/ru/articles/965890/
#автотесты #qa #qa_automation #python #golang #автоматизация_тестирования #лучшие_практики #моки #рефакторинг #flakyтесты
-
Лучшие практики автоматизации тестирования: 9 принципов стабильных автотестов
Почему автотесты становятся нестабильными и перестают приносить пользу? Разбираем системные причины флаков, бессмысленных ретраев и бесконечных E2E-монстров. Практические принципы: моки, изоляция, атомарность и минимализм — без философии, только инженерия.
https://habr.com/ru/articles/965890/
#автотесты #qa #qa_automation #python #golang #автоматизация_тестирования #лучшие_практики #моки #рефакторинг #flakyтесты
-
Моки в тестировании микросервисов с кучей интеграций — кейс финтех-приложения
Привет, Хабр! Я Святослав Волохов, QA-инженер в AGIMA . Тот, кто хоть раз тестировал сложный интеграционный сервис с десятками зависимостей и внешними API, да еще и в финтехе, знает — без грамотно выстроенной системы тестирования не обойтись. В этой статье хочу поделиться историей о том, как наша команда работала над масштабным финансовым сервисом с большим количеством интеграций. Это продуктовая экосистема, где можно оформить вклад, купить облигации, застраховать квартиру, получить рекомендации по финансам и многое другое. Расскажу о сложностях, с которыми мы столкнулись, и об их решениях: берите на заметку, особенно если работаете над enterprise-проектами и вы — начинающий специалист.
https://habr.com/ru/companies/agima/articles/931814/
#моки #тестирование_микросервисов #тестирование_интеграций #тестирование_в_финтех #тестирование_мобильных_приложений
-
Моки в тестировании микросервисов с кучей интеграций — кейс финтех-приложения
Привет, Хабр! Я Святослав Волохов, QA-инженер в AGIMA . Тот, кто хоть раз тестировал сложный интеграционный сервис с десятками зависимостей и внешними API, да еще и в финтехе, знает — без грамотно выстроенной системы тестирования не обойтись. В этой статье хочу поделиться историей о том, как наша команда работала над масштабным финансовым сервисом с большим количеством интеграций. Это продуктовая экосистема, где можно оформить вклад, купить облигации, застраховать квартиру, получить рекомендации по финансам и многое другое. Расскажу о сложностях, с которыми мы столкнулись, и об их решениях: берите на заметку, особенно если работаете над enterprise-проектами и вы — начинающий специалист.
https://habr.com/ru/companies/agima/articles/931814/
#моки #тестирование_микросервисов #тестирование_интеграций #тестирование_в_финтех #тестирование_мобильных_приложений
-
Моки в тестировании микросервисов с кучей интеграций — кейс финтех-приложения
Привет, Хабр! Я Святослав Волохов, QA-инженер в AGIMA . Тот, кто хоть раз тестировал сложный интеграционный сервис с десятками зависимостей и внешними API, да еще и в финтехе, знает — без грамотно выстроенной системы тестирования не обойтись. В этой статье хочу поделиться историей о том, как наша команда работала над масштабным финансовым сервисом с большим количеством интеграций. Это продуктовая экосистема, где можно оформить вклад, купить облигации, застраховать квартиру, получить рекомендации по финансам и многое другое. Расскажу о сложностях, с которыми мы столкнулись, и об их решениях: берите на заметку, особенно если работаете над enterprise-проектами и вы — начинающий специалист.
https://habr.com/ru/companies/agima/articles/931814/
#моки #тестирование_микросервисов #тестирование_интеграций #тестирование_в_финтех #тестирование_мобильных_приложений
-
Моки в тестировании микросервисов с кучей интеграций — кейс финтех-приложения
Привет, Хабр! Я Святослав Волохов, QA-инженер в AGIMA . Тот, кто хоть раз тестировал сложный интеграционный сервис с десятками зависимостей и внешними API, да еще и в финтехе, знает — без грамотно выстроенной системы тестирования не обойтись. В этой статье хочу поделиться историей о том, как наша команда работала над масштабным финансовым сервисом с большим количеством интеграций. Это продуктовая экосистема, где можно оформить вклад, купить облигации, застраховать квартиру, получить рекомендации по финансам и многое другое. Расскажу о сложностях, с которыми мы столкнулись, и об их решениях: берите на заметку, особенно если работаете над enterprise-проектами и вы — начинающий специалист.
https://habr.com/ru/companies/agima/articles/931814/
#моки #тестирование_микросервисов #тестирование_интеграций #тестирование_в_финтех #тестирование_мобильных_приложений
-
Почему @patch из unittest.mock ломает вам тесты, если не указать autospec=True
Привет, Хабр! Сегодня разберёмся, почему без autospec=True ваш безобидный @patch из unittest.mock может превратить зелёный репорт в мину замедленного действия. Смысл patch() прост: отрезаем внешний мир, подсовываем фейковый объект и гоняем логику изолированно. Но если не включить autospec , мок превращается в пластилин — к нему прилипает любой метод, любые аргументы, и тесты радостно хлопают ладоши, даже когда в коде опечатка или нарушена сигнатура.
https://habr.com/ru/companies/otus/articles/901534/
#python #моки #pytest #модульное_тестирование #python_qa_engineer #test_isolation
-
Почему @patch из unittest.mock ломает вам тесты, если не указать autospec=True
Привет, Хабр! Сегодня разберёмся, почему без autospec=True ваш безобидный @patch из unittest.mock может превратить зелёный репорт в мину замедленного действия. Смысл patch() прост: отрезаем внешний мир, подсовываем фейковый объект и гоняем логику изолированно. Но если не включить autospec , мок превращается в пластилин — к нему прилипает любой метод, любые аргументы, и тесты радостно хлопают ладоши, даже когда в коде опечатка или нарушена сигнатура.
https://habr.com/ru/companies/otus/articles/901534/
#python #моки #pytest #модульное_тестирование #python_qa_engineer #test_isolation
-
Почему @patch из unittest.mock ломает вам тесты, если не указать autospec=True
Привет, Хабр! Сегодня разберёмся, почему без autospec=True ваш безобидный @patch из unittest.mock может превратить зелёный репорт в мину замедленного действия. Смысл patch() прост: отрезаем внешний мир, подсовываем фейковый объект и гоняем логику изолированно. Но если не включить autospec , мок превращается в пластилин — к нему прилипает любой метод, любые аргументы, и тесты радостно хлопают ладоши, даже когда в коде опечатка или нарушена сигнатура.
https://habr.com/ru/companies/otus/articles/901534/
#python #моки #pytest #модульное_тестирование #python_qa_engineer #test_isolation
-
Почему @patch из unittest.mock ломает вам тесты, если не указать autospec=True
Привет, Хабр! Сегодня разберёмся, почему без autospec=True ваш безобидный @patch из unittest.mock может превратить зелёный репорт в мину замедленного действия. Смысл patch() прост: отрезаем внешний мир, подсовываем фейковый объект и гоняем логику изолированно. Но если не включить autospec , мок превращается в пластилин — к нему прилипает любой метод, любые аргументы, и тесты радостно хлопают ладоши, даже когда в коде опечатка или нарушена сигнатура.
https://habr.com/ru/companies/otus/articles/901534/
#python #моки #pytest #модульное_тестирование #python_qa_engineer #test_isolation
-
[Перевод] Разница между очисткой, сбросом и восстановлением моков
В данной статье мы подробно рассмотрим различия между операциями очистки (clearing), сброса (resetting) и восстановления (restoring) моков в процессе тестирования программного обеспечения. Вы узнаете, когда и в каких ситуациях применяется каждая из этих стратегий, а также какие преимущества и особенности они предоставляют. Мы также приведем практические примеры использования, чтобы продемонстрировать, как правильно управлять моками для повышения эффективности и надежности ваших тестов.
-
[Перевод] Разница между очисткой, сбросом и восстановлением моков
В данной статье мы подробно рассмотрим различия между операциями очистки (clearing), сброса (resetting) и восстановления (restoring) моков в процессе тестирования программного обеспечения. Вы узнаете, когда и в каких ситуациях применяется каждая из этих стратегий, а также какие преимущества и особенности они предоставляют. Мы также приведем практические примеры использования, чтобы продемонстрировать, как правильно управлять моками для повышения эффективности и надежности ваших тестов.
-
[Перевод] Разница между очисткой, сбросом и восстановлением моков
В данной статье мы подробно рассмотрим различия между операциями очистки (clearing), сброса (resetting) и восстановления (restoring) моков в процессе тестирования программного обеспечения. Вы узнаете, когда и в каких ситуациях применяется каждая из этих стратегий, а также какие преимущества и особенности они предоставляют. Мы также приведем практические примеры использования, чтобы продемонстрировать, как правильно управлять моками для повышения эффективности и надежности ваших тестов.
-
[Перевод] Разница между очисткой, сбросом и восстановлением моков
В данной статье мы подробно рассмотрим различия между операциями очистки (clearing), сброса (resetting) и восстановления (restoring) моков в процессе тестирования программного обеспечения. Вы узнаете, когда и в каких ситуациях применяется каждая из этих стратегий, а также какие преимущества и особенности они предоставляют. Мы также приведем практические примеры использования, чтобы продемонстрировать, как правильно управлять моками для повышения эффективности и надежности ваших тестов.
-
[Перевод] Четыре принципа разработки ПО, которым я научился на горьком опыте
Недавно я спроектировал и написал огромный сервис, и в прошлом месяце (наконец-то) состоялся его запуск. В процессе проектирования и имплементации я обнаружил, что ряд закономерностей, которые я приведу ниже, раз за разом всплывает в самых разных сценариях. Эти закономерности настолько устойчивы, что, рискну предположить, знание как минимум одной из них будет актуально для любого читателя в отношении проекта, разработкой которого он сейчас занят. Но если даже их невозможно применить непосредственно к тому, над чем вы работаете сейчас, надеюсь, эти принципы послужат полезной пищей для ума, а также основанием для комментариев и возражений, которые вы вольны оставлять под статьей. Хотелось бы отметить здесь одну вещь: разумеется, для каждого из принципов есть свое место и время. Как и во всех прочих случаях, важно учитывать нюансы. Я склонен держаться этих заключений в общем случае, по той причине что, как я вижу по опыту инспекции кода и документации, люди часто принимают противоположный образ действия как вариант по умолчанию.
https://habr.com/ru/companies/productivity_inside/articles/827062/
-
[Перевод] Четыре принципа разработки ПО, которым я научился на горьком опыте
Недавно я спроектировал и написал огромный сервис, и в прошлом месяце (наконец-то) состоялся его запуск. В процессе проектирования и имплементации я обнаружил, что ряд закономерностей, которые я приведу ниже, раз за разом всплывает в самых разных сценариях. Эти закономерности настолько устойчивы, что, рискну предположить, знание как минимум одной из них будет актуально для любого читателя в отношении проекта, разработкой которого он сейчас занят. Но если даже их невозможно применить непосредственно к тому, над чем вы работаете сейчас, надеюсь, эти принципы послужат полезной пищей для ума, а также основанием для комментариев и возражений, которые вы вольны оставлять под статьей. Хотелось бы отметить здесь одну вещь: разумеется, для каждого из принципов есть свое место и время. Как и во всех прочих случаях, важно учитывать нюансы. Я склонен держаться этих заключений в общем случае, по той причине что, как я вижу по опыту инспекции кода и документации, люди часто принимают противоположный образ действия как вариант по умолчанию.
https://habr.com/ru/companies/productivity_inside/articles/827062/
-
[Перевод] Четыре принципа разработки ПО, которым я научился на горьком опыте
Недавно я спроектировал и написал огромный сервис, и в прошлом месяце (наконец-то) состоялся его запуск. В процессе проектирования и имплементации я обнаружил, что ряд закономерностей, которые я приведу ниже, раз за разом всплывает в самых разных сценариях. Эти закономерности настолько устойчивы, что, рискну предположить, знание как минимум одной из них будет актуально для любого читателя в отношении проекта, разработкой которого он сейчас занят. Но если даже их невозможно применить непосредственно к тому, над чем вы работаете сейчас, надеюсь, эти принципы послужат полезной пищей для ума, а также основанием для комментариев и возражений, которые вы вольны оставлять под статьей. Хотелось бы отметить здесь одну вещь: разумеется, для каждого из принципов есть свое место и время. Как и во всех прочих случаях, важно учитывать нюансы. Я склонен держаться этих заключений в общем случае, по той причине что, как я вижу по опыту инспекции кода и документации, люди часто принимают противоположный образ действия как вариант по умолчанию.
https://habr.com/ru/companies/productivity_inside/articles/827062/
-
Эмуляция бэкенда: как разрабатывать изолированный фронтенд с помощью Mock Service Worker
Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw , и в ней достаточно много важных обновлений.
https://habr.com/ru/articles/780200/
#service_worker #mocks #mock #mock_service_worker #mock_server #api_mocking #моки #эмуляция_бэкенда #e2eтесты
-
Эмуляция бэкенда: как разрабатывать изолированный фронтенд с помощью Mock Service Worker
Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw , и в ней достаточно много важных обновлений.
https://habr.com/ru/articles/780200/
#service_worker #mocks #mock #mock_service_worker #mock_server #api_mocking #моки #эмуляция_бэкенда #e2eтесты