Андрей, имеется ввиду тесты на "живых" компонентах. Проще, потому что в общем случае в интеграционыых тестах всё сводится к "отправил запрос - провалидировал в ответ". В компонентных тестах часто мы сами генерим этот ответ на запрос "живого" сервиса. При этом необходимо строго соблюдать логику поведения системы, понимать какие обязательные сообщения система шлёт на событие, какие опциональные. Нужно отправить всё в точности так, как сделала бы "живая" система. В общем и целом в компонентных тестах довольно много мест, за которыми можно не уследить либо получить такой ответ от системы, который ничего не скажет о первопричинах именно такого ответа. Плюс сложность в том, что поскольку приходится работать с деталями реализации, часто поведение не описано в документации и приходится либо самому разбираться в коде приложения, либо отнимать время у более дорогого специалиста от разработки.
Мы не то чтобы совсем отнекиваемся от этих тестов. Как было сказано в статье, иногда этот подход уместен. И у нас такие тесты тоже есть. Но на мой взгляд, и фаззинг, и рандомизация не самодостаточны и часто подходят скорее для исследования. Сначала очевидные детерминированные кейсы, потом уже можно и рандомизированные добавлять для поиска новых. Так и наши рандомизированные тесты идут “вместе“, а не “вместо“. В приведенном примере же был только рандомный тест, без простых тестов со строгим поведением.
На устном собеседовании кандидаты часто подвержены волнению, и на какие-то вопросы, проверяющие то же, что тестовое, могут не ответить. Не по незнанию, а просто из-за усталости, напряжения, формата вопрос-ответ или чего-то другого.
У нас были кандидаты, которые на тестовом показали себя лучше, чем на собеседовании. К тому же на устном собеседовании есть ряд классических вопросов, ответы на которые можно заучить, произвести хорошее впечатление, а потом посыпаться в задании.
Конечно, есть кандидаты, отказавшиеся делать тестовое, но на удивление их было крайне мало.
Добрый день! Как написано в статье, тестовое проверяет не столько стиль кода, сколько, скажем так, ход мысли человека. Стиля кода, пожалуй, касаются только пункты про засовывание нескольких тестов в один (но есть же атомарность, которая на стиль никак не влияет) и про “говорящие” названия тестов и переменных. Не думаю, что, например, отсутствие в тесте адекватной проверки является различием в стиле – это неудачный тест. Если бы результаты устного собеседования всегда совпадали с результатами тестового, то мы бы, полагаю, от него отказались. Но, увы, пока что это не так. К примеру, по нашей статистике из дошедших до теста и выполнивших его кандидатов похвастаться удовлетворительным результатом могут не более 30%.
Здравствуйте! Ядро - это часть системы и другие компоненты переиспользуют его, что в свою очередь добавляет еще как минимум одно звено, отделяющее ядро от конечного пользователя. В связи с этим появляются интеграционные вопросы. Но если говорить конкретно за баги, которые отношение к ядру, то с каждым годом их количество заметно сокращается, если грубо оценивать в 2-3 раза.
Доброго времени суток! Отвечу по порядку: 1. Пока идет разработка (ядра и тестов) в фиче-ветке никто не запрещает запустить точечно или полный набор тестов для самоконтроля. Но когда работа завершена и готова вливаться в мастер, все тесты должны быть успешно пройдены. Набор тестов один. Как правило разработчик или QA знают в какая из групп тестов наиболее уязвима/интересна при разработки новой фичи. При первичной отладки ребята запускают именно эти группы. Каждая группа тестов выполняется 15-20 мин. 2. На одном независимом тестовом окружении поднимается вся система (30 с лишнем компонентов), далее на нем выполняется одна группа тестов. При одновременном мерже нескольких разработчиков, пайплайны встают в очередь. Как только ВМ освобождается, она передается следующему мержу. 3. Почти все тесты генерят тестовые данные для себя через внешние точки доступа к системе (то что доступно клиентам). Но есть группы тестов которые дополнительно для себя подготавливают тестовое окружение через: внутренние протоколы / запросы в БД / подкладка специальных снапшотов. Это отдельные группы тестов, они как и все остальные, выполняется изолировано на ВМ. Как правило данный тип тестов проверяет очень специфические use-кейсы.
Гейты это часть системы (проект ядра). Система живет в одном репозитории. В этом же репозитории, рядом находится фреймфорк-коннектор, для облегчения совместимости. Раньше фреймфорк находился в отдельной репе.
FIX Gateway у нас свой. Дополнительно мы используем QuickFIX в тестах - для валидации структур FIX-собщений. FIX очень капризный, гарантия совместимости гейта с клиентами должна быть обязательно подтверждена.
Хороший вопрос. Когда строили тестовый проект, фреймворк-коннектор со своими кодеками жил в отдельной репе. И действительно была боль следить и синхронизировать репы. В конечном итоге терпение кончилось и репы объединили. Теперь, когда меняется формат сообщения, кодек сразу на это ругается и программист ядра или QA самостоятельно тюнят кодеки под новые требования.
Андрей, имеется ввиду тесты на "живых" компонентах. Проще, потому что в общем случае в интеграционыых тестах всё сводится к "отправил запрос - провалидировал в ответ".
В компонентных тестах часто мы сами генерим этот ответ на запрос "живого" сервиса. При этом необходимо строго соблюдать логику поведения системы, понимать какие обязательные сообщения система шлёт на событие, какие опциональные. Нужно отправить всё в точности так, как сделала бы "живая" система. В общем и целом в компонентных тестах довольно много мест, за которыми можно не уследить либо получить такой ответ от системы, который ничего не скажет о первопричинах именно такого ответа. Плюс сложность в том, что поскольку приходится работать с деталями реализации, часто поведение не описано в документации и приходится либо самому разбираться в коде приложения, либо отнимать время у более дорогого специалиста от разработки.
Мы не то чтобы совсем отнекиваемся от этих тестов. Как было сказано в статье, иногда этот подход уместен. И у нас такие тесты тоже есть. Но на мой взгляд, и фаззинг, и рандомизация не самодостаточны и часто подходят скорее для исследования. Сначала очевидные детерминированные кейсы, потом уже можно и рандомизированные добавлять для поиска новых. Так и наши рандомизированные тесты идут “вместе“, а не “вместо“. В приведенном примере же был только рандомный тест, без простых тестов со строгим поведением.
На устном собеседовании кандидаты часто подвержены волнению, и на какие-то вопросы, проверяющие то же, что тестовое, могут не ответить. Не по незнанию, а просто из-за усталости, напряжения, формата вопрос-ответ или чего-то другого.
У нас были кандидаты, которые на тестовом показали себя лучше, чем на собеседовании. К тому же на устном собеседовании есть ряд классических вопросов, ответы на которые можно заучить, произвести хорошее впечатление, а потом посыпаться в задании.
Конечно, есть кандидаты, отказавшиеся делать тестовое, но на удивление их было крайне мало.
Добрый день! Как написано в статье, тестовое проверяет не столько стиль кода, сколько, скажем так, ход мысли человека. Стиля кода, пожалуй, касаются только пункты про засовывание нескольких тестов в один (но есть же атомарность, которая на стиль никак не влияет) и про “говорящие” названия тестов и переменных. Не думаю, что, например, отсутствие в тесте адекватной проверки является различием в стиле – это неудачный тест. Если бы результаты устного собеседования всегда совпадали с результатами тестового, то мы бы, полагаю, от него отказались. Но, увы, пока что это не так. К примеру, по нашей статистике из дошедших до теста и выполнивших его кандидатов похвастаться удовлетворительным результатом могут не более 30%.
Здравствуйте!
Ядро - это часть системы и другие компоненты переиспользуют его, что в свою очередь добавляет еще как минимум одно звено, отделяющее ядро от конечного пользователя. В связи с этим появляются интеграционные вопросы. Но если говорить конкретно за баги, которые отношение к ядру, то с каждым годом их количество заметно сокращается, если грубо оценивать в 2-3 раза.
Доброго времени суток!
Отвечу по порядку:
1. Пока идет разработка (ядра и тестов) в фиче-ветке никто не запрещает запустить точечно или полный набор тестов для самоконтроля. Но когда работа завершена и готова вливаться в мастер, все тесты должны быть успешно пройдены. Набор тестов один. Как правило разработчик или QA знают в какая из групп тестов наиболее уязвима/интересна при разработки новой фичи. При первичной отладки ребята запускают именно эти группы. Каждая группа тестов выполняется 15-20 мин.
2. На одном независимом тестовом окружении поднимается вся система (30 с лишнем компонентов), далее на нем выполняется одна группа тестов.
При одновременном мерже нескольких разработчиков, пайплайны встают в очередь. Как только ВМ освобождается, она передается следующему мержу.
3. Почти все тесты генерят тестовые данные для себя через внешние точки доступа к системе (то что доступно клиентам). Но есть группы тестов которые дополнительно для себя подготавливают тестовое окружение через: внутренние протоколы / запросы в БД / подкладка специальных снапшотов. Это отдельные группы тестов, они как и все остальные, выполняется изолировано на ВМ. Как правило данный тип тестов проверяет очень специфические use-кейсы.
Гейты это часть системы (проект ядра). Система живет в одном репозитории. В этом же репозитории, рядом находится фреймфорк-коннектор, для облегчения совместимости. Раньше фреймфорк находился в отдельной репе.
Примерный размер одной транзакции: 0.25-1 Кбайт. Время процессинга дампа действительно большое.
FIX Gateway у нас свой. Дополнительно мы используем QuickFIX в тестах - для валидации структур FIX-собщений. FIX очень капризный, гарантия совместимости гейта с клиентами должна быть обязательно подтверждена.
Хороший вопрос.
Когда строили тестовый проект, фреймворк-коннектор со своими кодеками жил в отдельной репе. И действительно была боль следить и синхронизировать репы. В конечном итоге терпение кончилось и репы объединили. Теперь, когда меняется формат сообщения, кодек сразу на это ругается и программист ядра или QA самостоятельно тюнят кодеки под новые требования.
Сейчас это время 15-20 мин. Стараемся группировать тесты так, что бы длительность прохождения у всех групп была одинаковая.