Comments 9
Спасибо за антипаттерны!
А ещё integration testing это не фейки и песочницы, это реальные стыки систем. Это, например, тестирование DAL уровня запросв (методов Repository) с реальной базой. тестррование методов repository по обращению к сервису с реальным сервисом по http. Но никак не с фейкам. Нет песочницы и тестового аккаунта к реальной системе? Значит для этого куска нельзя реализовать интеграционные тесты. Обходитесь юнитами. И уже тем более интеграционное тестирование не «просто уровнем выше будем тестировать: наделали кучу зависимостей разных подсистем и один монстро-тест запустили, который и в базу лезет и в сервис шлёт и в очередь». Это самая распространённая ошибка, которая становится причиной: «ой… чё-то тесты опять упали», а потом «ну да, есть тесты, но поддерживать их тяжко, потому не запускали давно»
Для автотестов делается свой сервис со стабами, фейк у вас в статье. В который скармливается «ожидаемый ответ на ожидаемый запрос» а ля Setup из библиотеки Moq только по HTTP
И погнали тесты делать любые. QA должен был знать такие базовые вещи, прежде чем использовать карту. Но это ещё большой вопрос, надо ли это делать, когда достаточно один раз от реальной системы получить ответы, понять логику и всё заменить моками.
Ещё бы. Когда на уровень юнит-тестов бизнес логики лезем е2е тестами, да ещё и с нестабильным инструментарием. Разделять, это нужно разделять. Бизнес логика тестируется только юнитами и только моками, никаких песочниц от эппл. Песочница это е2е тесты и частично интеграционные.
нужно трекать такие изменения. документацию или запросами к реальному серверу раз в день, например. Как минимум версию сервиса трекать и\или xsd схему.
ЗЫ
О боже, опять это дурное слово из рунглиша — «нужны знания и экспертиза». Пришлите адрес, вышлю ссылку на словарь Ожегова.
Экспертиза в русском языке это документ, заключение по результатам исследований: «проводить экспертизу».
В том значении, в котором автор пытается применять слово переводя с английского, есть добротное выражение: «знание и опыт» или «специальные знания». Но никак не «знания и экспертиза».
Нужные знания и опыт. Или нужные опыт и специальные знания.
А ещё integration testing это не фейки и песочницы, это реальные стыки систем. Это, например, тестирование DAL уровня запросв (методов Repository) с реальной базой. тестррование методов repository по обращению к сервису с реальным сервисом по http. Но никак не с фейкам. Нет песочницы и тестового аккаунта к реальной системе? Значит для этого куска нельзя реализовать интеграционные тесты. Обходитесь юнитами. И уже тем более интеграционное тестирование не «просто уровнем выше будем тестировать: наделали кучу зависимостей разных подсистем и один монстро-тест запустили, который и в базу лезет и в сервис шлёт и в очередь». Это самая распространённая ошибка, которая становится причиной: «ой… чё-то тесты опять упали», а потом «ну да, есть тесты, но поддерживать их тяжко, потому не запускали давно»
Но однажды один QA-инженер из нашей команды узнал её данные. Имея благие намерения, он решил реализовать автотесты.
Для автотестов делается свой сервис со стабами, фейк у вас в статье. В который скармливается «ожидаемый ответ на ожидаемый запрос» а ля Setup из библиотеки Moq только по HTTP
И погнали тесты делать любые. QA должен был знать такие базовые вещи, прежде чем использовать карту. Но это ещё большой вопрос, надо ли это делать, когда достаточно один раз от реальной системы получить ответы, понять логику и всё заменить моками.
Последствия использования песочниц внизу пирамиды — появление различных инфраструктурных проблем:
Ещё бы. Когда на уровень юнит-тестов бизнес логики лезем е2е тестами, да ещё и с нестабильным инструментарием. Разделять, это нужно разделять. Бизнес логика тестируется только юнитами и только моками, никаких песочниц от эппл. Песочница это е2е тесты и частично интеграционные.
формат нотификаций, а тест при этом давал ложноположительные результаты
нужно трекать такие изменения. документацию или запросами к реальному серверу раз в день, например. Как минимум версию сервиса трекать и\или xsd схему.
ЗЫ
О боже, опять это дурное слово из рунглиша — «нужны знания и экспертиза». Пришлите адрес, вышлю ссылку на словарь Ожегова.
Экспертиза в русском языке это документ, заключение по результатам исследований: «проводить экспертизу».
В том значении, в котором автор пытается применять слово переводя с английского, есть добротное выражение: «знание и опыт» или «специальные знания». Но никак не «знания и экспертиза».
Нужные знания и опыт. Или нужные опыт и специальные знания.
Спасибо за важное дополнение. Конечно, всего в одну статью не уместишь: у нас готовится следующая статья от моего коллеги, с которым мы вместе делали доклад на Гейзенбаге, там как раз будет про то, что в каждом конкретном случае требуется оценка рисков и их покрытие. Мы также расскажем, на основе чего эти риски выявлять. Про рунглиш — да, в Лондоне возникает такая профессиональная деформация, иногда забываешь, как слова пишутся.
В крупных организациях на каждого внешнего поставщика услуг заводят отдельный журнал (электронный) и назначают выделенного работника, который отвечает за все вопросы по этому поставщику, которые возникают у безопасноиков/разработчиков/тестировщиков, такие как-то:
Так что знания и экспертиза — это хорошо, но еще нужно иметь менеджера этих самых знаний, который будет предоставлять их команде по мере необходимости и поддерживать их у себя в журнале в актуальном состоянии.
- Почему внезапно сменился HTTPS сертификат на API URI?
- Зачем поставщик начинает мне слать 5xx ошибки если я делаю больше 10 одновременных вызовов API?
- Как мне проверить метод XYZ под версию 1.2.3, если у поставщика выложена документация только на 1.1.2?
Так что знания и экспертиза — это хорошо, но еще нужно иметь менеджера этих самых знаний, который будет предоставлять их команде по мере необходимости и поддерживать их у себя в журнале в актуальном состоянии.
Очень классное дополнение, спасибо! Надо попробовать в своей работе. Это позволит также формализовать свои знания и, в случае неоходимости, поделиться ими с коллегами. В нашем рабочем процессе закрепление человека за определенной областью не очень приветствуется, но ведение журнала подходит и в этом случае.
UFO just landed and posted this here
Рассматривая клиентское приложение или систему «приложение-сервер» (которые далее в коментарии я буду называть просто приложением), мы имеем дело с детерминированным конечным автоматом (ДКА), который обладает ограниченным (возможно очень большим, но ограниченным) числом состояний. Проблема подключения сторонних сервисов, которыми является, например, платежный провайдер, заключается в том, что на одну из точек входа начинают поступать сигналы на изменение состояний, которые a) нам известны, но плохо контролируются нами, б) нам неизвестны. Соотвтетственно, ответ на вопрос «ЧТО мы тестируем?» разбивается на две части: a) для известных сигналов черного ящика мы тестируем, что вся цепочка состояний нашего ДКА изменяется в соответствии с нашими ожиданиями, б) что мы не получаем сигналы, которые нам неизвестны.
Первая проблема заключается в том, что сигналы нами плохо контролиуруются (распределены во времени в реальном кейсе, требуют сложной настройки и прочее). Решается эта проблема идеально любым методом убирания внешних зависимостей, по сути о ней очень подробно написано в этой статье. Поэтому же в статью добавлен раздел о важности наличия знаний обо всех возможных состояниях до реализации взаимодействия. На этом этапе цель — перевести как можно больше сигналов из категории неизвестных в категорию узнаваемых приложением.
Вторая проблема — поступление на вход приложения неизвестного сигнала. Она очень серьезная, и решается она по-разному. В комментарии выше, например, коллега предлагает вести журнал и иметь в отделе менеджера, контролирующего изменения от внешней системы. У нас на текущий момент выполняется сбор всех приходящих нотификаций от внешних систем. Любые изменения сигналов мы рассматриваем как риск. Узнать о них (если нас не уведомляют провайдеры заранее) мы можем постфактум (и у нас были прецеденты), посмотреть в логах, что к нам стало приходить, увидеть изменения и отреагировать на них. Но это все равно не гарантирует нам своевременную реакцию на изменения. Если мы хотим получать информацию о неизвестных сигналах, как можно раньше, то в идеале мы должны валидировать приходящие к нам запросы (например, по xsd или json схемам), но здесь я немного хитрю, называя это риском. При рассмотрении риска мы должны учитывать вероятность его реализации, негативное влияние от его реализации и стоимость на его покрытие. В нашей ситуации решение с валидацией пока представляется достаточно дорогим, потому что это аналитическая или даже экспертная система, которая требует серьезных ресурсов на создание и поддержку. Да, изменения случаются, да они могут принести серьезный вред (и мы рассмотрим пример в следующей статье, которую готовит мой коллега по мотивам выступления на Гейзенбаге (ссылка в статье)). Но вероятность этого пока не настолько высока, чтобы потратить ресурсы на валидацю по схеме, поэтому мы ограничиваемся визуальным анализом статистики и логов, и немного уменьшаем неопределенность, покрывая интеграционными тестами с использованием реального платежа или песочницы.
PS Вообще, своим коментарием вы подняли проблему, которую лично я считаю одной из ключевых в коммуникации, когда объект исследования подменяется методологией и потом забывается, а о чем мы вообще тут говорили. Ответ на этот вопрос помог сместить акценты, как мне кажется в нужном направлении. Спасибо!
Первая проблема заключается в том, что сигналы нами плохо контролиуруются (распределены во времени в реальном кейсе, требуют сложной настройки и прочее). Решается эта проблема идеально любым методом убирания внешних зависимостей, по сути о ней очень подробно написано в этой статье. Поэтому же в статью добавлен раздел о важности наличия знаний обо всех возможных состояниях до реализации взаимодействия. На этом этапе цель — перевести как можно больше сигналов из категории неизвестных в категорию узнаваемых приложением.
Вторая проблема — поступление на вход приложения неизвестного сигнала. Она очень серьезная, и решается она по-разному. В комментарии выше, например, коллега предлагает вести журнал и иметь в отделе менеджера, контролирующего изменения от внешней системы. У нас на текущий момент выполняется сбор всех приходящих нотификаций от внешних систем. Любые изменения сигналов мы рассматриваем как риск. Узнать о них (если нас не уведомляют провайдеры заранее) мы можем постфактум (и у нас были прецеденты), посмотреть в логах, что к нам стало приходить, увидеть изменения и отреагировать на них. Но это все равно не гарантирует нам своевременную реакцию на изменения. Если мы хотим получать информацию о неизвестных сигналах, как можно раньше, то в идеале мы должны валидировать приходящие к нам запросы (например, по xsd или json схемам), но здесь я немного хитрю, называя это риском. При рассмотрении риска мы должны учитывать вероятность его реализации, негативное влияние от его реализации и стоимость на его покрытие. В нашей ситуации решение с валидацией пока представляется достаточно дорогим, потому что это аналитическая или даже экспертная система, которая требует серьезных ресурсов на создание и поддержку. Да, изменения случаются, да они могут принести серьезный вред (и мы рассмотрим пример в следующей статье, которую готовит мой коллега по мотивам выступления на Гейзенбаге (ссылка в статье)). Но вероятность этого пока не настолько высока, чтобы потратить ресурсы на валидацю по схеме, поэтому мы ограничиваемся визуальным анализом статистики и логов, и немного уменьшаем неопределенность, покрывая интеграционными тестами с использованием реального платежа или песочницы.
PS Вообще, своим коментарием вы подняли проблему, которую лично я считаю одной из ключевых в коммуникации, когда объект исследования подменяется методологией и потом забывается, а о чем мы вообще тут говорили. Ответ на этот вопрос помог сместить акценты, как мне кажется в нужном направлении. Спасибо!
UFO just landed and posted this here
Для тестирования интеграций нужны знания и экспертиза
Экспертиза — в русском «это тестирование с целью оценки».
А в английском сходное по написанию слово — это, действительно, «компетенция, уровень знаний».
Если употреблено в английском смысле — то у вас тавтология «Для тестирования интеграций нужны знания и уровень знаний»
А если в русском — то там ничего нет про «тестирование с целью проверки».
В данном случае используется значение в русском
В сухом остатке — это исследование экспертом. «Необходимы знания и экспертиза» в данном контексте означает, что либо вы знаете все кейсы (например, потому что вы общаетесь с представителями провайдера, уверены, что версия та же, что описана в имеющейся документации). Либо вы проводите исследование, для которого вам нужны экспертные навыки и стартовые данные (например, критерии оценки или опорные точки, которые в статье и предложены). Поэтому здесь как мне кажется нет ни противоречия, ни тавтологии.
При переводе на английский будет использован только термин expertise, потому что, как вы совершенно верно заметили, в английском языке это слово уже включает и навыки исследования, и знания.
ЭКСПЕРТИЗА (франц. expertise, от лат. expertus — опытный) — исследование специалистом (экспертом) каких-либо вопросов, решение которых требует специальных познаний в области науки, техники, искусства и т. д. (Большой энциклопедический словарь)
Экспертиза — Исследование Экспертами каких-либо вопросов, решение которых требует специальных познаний в области науки, техники, искусства и т. д. (Большая советская энциклопедия)
Экспертиза — [< лат.; см. эксперт] – исследование и разрешение при помощи сведущих людей какого-либо вопроса, требующего специальных знаний, например, врачебная экспертиза, бухгалтерская экспертиза (Большой словарь иностранных слов)
В сухом остатке — это исследование экспертом. «Необходимы знания и экспертиза» в данном контексте означает, что либо вы знаете все кейсы (например, потому что вы общаетесь с представителями провайдера, уверены, что версия та же, что описана в имеющейся документации). Либо вы проводите исследование, для которого вам нужны экспертные навыки и стартовые данные (например, критерии оценки или опорные точки, которые в статье и предложены). Поэтому здесь как мне кажется нет ни противоречия, ни тавтологии.
При переводе на английский будет использован только термин expertise, потому что, как вы совершенно верно заметили, в английском языке это слово уже включает и навыки исследования, и знания.
Sign up to leave a comment.
Как не потерять деньги в черном ящике: методы тестирования биллинга