Коллеги, когда встаёт вопрос тестирования и, может, автоматизации REST API

сервисов, как вы решаете: когда писать тесты в Postman, а когда выбираете фреймворк типа jest, mocha и тд и пишите тесты (юнит и (или) интеграционные, e2e)? В зависимости от того, что покрыли разрабы

Пишешь список требований (текущих и потенциальных) к инструменту, пишешь список потенциальных инструментов (Postman, jest, rest assured, etc.), пишешь список констрейнтов (бесплатный, опенсорсный, codeless, etc.), расставляешь приоритеты для каждого требования и оцениваешь поддержку каждого требования каждым инструментом. Ну и по итогам смотришь на получившуюся матрицу и принимаешь решение, какой инструмент удовлетворяет наибольшему количеству требований и требует наименьших трудозатрат и вписывается в констрейнты

А всегда ли можно определить список требований к инструменту, если у тебя еще нет этого проекта. Обычно по мере расширения проекта список немного видоизменяется. Ну, конечно, если ваш 3-4-й проект, то, наверное, понятно сразу, но в изначальном посте написано: встает вопрос...

Если разочек что-то проверить-поиграться, то открываю постман. Если сажусь писать тесты, закрываю и забываю про постман, и беру %frameworkname%

В зависимости от первый\не первый проект ты просто тратишь больше времени на ресерч и сбор требований. Планирование там, роадмап, вот это всё.

Если проект абстрактный, то логичнее взять максимально кастомабельный фреймворк, тот же jest, и прикручивать к нему фичи по мере необходимости. Если изначально взять постман, то может наступить момент, когда окажется, что очередную фичу нельзя имплементировать в постмане (работа с бд, например) и придется всё равно брать %frameworkname% и мигрировать на него всё, что успели написать в постмане

Согласна с вами за одним исключением: это если ваши тесты точно не понадобится работать человеку, который не умеет в фреймворки, программирование и т.д. Я не знаю, в чем тут цимус, но с Постманом хардкорные мануалы работают, а с фреймворками нет, хотя с Постманом, имхо, разобраться полноценно может и еще и сложнее.

Ну, добавляете пункт “не требует программирования” в констрейнты, ставите ему приоритет и дальше по той же схеме. В итоге может оказаться, что дешевле научить людей нормальному программированию или нанять сдета, чем пытаться впилить постман туда, где его возможностей изначально не хватит

К кастомному фреймворку бдд обёртку можно прикрутить, опять же, и удовлетворить этим всех - и девелоперов, и ручников)

Если изменения постоянные и могут быть серьезными, то на постман. Потому как дернул эндпоинт, тут же быстренько накидал тестов. Когда уже стабильно начинает работать, то переносить все на чистовик с помощью фреймворка.

Спасибо всем за развернутые ответы по Postman/${framework}. Ещё такой вопрос: мои разрабы пишут unit тесты под бекенд, - вы проговариваете с разрабом что автоматизировать QA чтобы не перехлёстывать тесты?

Как правило, оно и так не перехлестывается, уровень проверок разный

Но порой я делаю полагаю юнит тесты и нахожу ошибку, - это значит разраб не доработал? То есть я только автоматизирую e2e, интеграцию с БД, если нужно,- так? То есть например автоматизирую заполнение формы и как заполненные поля идут POST запросом в другой сервис и валидирую правильность выполнения контракта от другого сервиса и как GET’ом можно подтянуть из БД запостенные данные. Типа того?

На всякий случай - запуск тестов через jUnit не делает их юнит-тестами :) А вообще да - вы, скорее всего, будете автоматизировать интеграционное взаимодействие.

Могу только присоединиться к ответу Андрея выше. Уровень тестов разный, дублирования проверок не будет. Поэтому в сами юнит-тесты я не смотрю, и с разрабами с этой точки зрения не советуюсь.

>это значит разраб не доработал? Это значит, что разрабу лень покрывать фичу тестами и/или он не разбирается в тест-дизайне. Обычно девелоперы пишут 1-2 хэппи пас теста и на этом всё. Соответственно, много юзкейсов остаются непокрытыми девелоперскими тестами и о них должен думать тестировщик. >вы проговариваете с разрабом что автоматизировать QA чтобы не перехлёстывать тесты? Об этом много пишут в статьях про пирамиду тестирования, но на деле это буллшит. Потому что девелоперы будут рефакторить/удалять свои тесты и не будут вас об этом уведомлять. Соответственно, тестовое покрытие со временем будет уменьшаться. Лучше 2 раза протестировать один кусок кода на разных уровнях, чем понадеяться на девелоперов и протестировать 0 раз

Нет, потому что дублирование проверок будет не полным, а даже если и будет - это скорее хорошо, чем плохо.

Пирамида тестирования так-то вообще не про это.

В том числе и про это)

Она про то, что бы держать тесты на том же уровне, что и объект тестирования. У юнитов и энд ту энд тестов объекты тестирования сильно разные. Даже если кодовая база тестируемый логики сильно пересекается.

Если бы это было единственным критерием, тогда это был бы прямоугольник тестирования

По поводу юнит-тестов (точнее, компонентных) встретился с таким подходом: в паке с интеграционными тестами лежат тесты со ссылками на некоторые компонентные. Таким образом, есть трассировка между некоторыми тест-кейсами и покрывающими их компонентными тестами. Звучит вроде логично, но выглядит странно.

Да в общем-то нет, потому что количество состояний объекта низкого уровня не отражает количество его состояний, задействованных в end-to-end сценариях.

Линковать тесты на разных уровнях пирамиды в целом не проблема, но сложно заставить всех тиммейтов следовать какому-то процессу поддержания этих линков в актуальном состоянии. И плюс тестеры должны ревьюить все девелоперские мерж реквесты на предмет изменения тестов, а девелоперы - ревьюить тестеров. В моём нынешнем проекте мы так и не пришли к какому-то общему процессу, хотя мы с девелоперами пишем тесты на одном уровне, в одном репе, и иногда дублируем друг друга. Решили просто положить наши тесты в разные пакеты и не считать дубликацию чем-то плохим)

Ну вот сам Фаулер большими буквами пишет *Avoid Test Duplication* https://martinfowler.com/articles/practical-test-pyramid.html#AvoidTestDuplication. Немало авторов понимают это по-своему и игнорируют заявление If a higher-level test gives you more confidence that your application works correctly, you should have it, в результате чего сводят всю концепцию к “тестируйте всю бизнес-логику на уровне юнит тестов и немножко потестируйте интеграции, тесты никогда не дублируйте”

Ну, в целом да, убедил. Но для продолжения холивара всё равно вброшу. :) Сам Фаулер большими буквами пишет: избегайте дублирования тестов. А потом приводит пример: Writing a unit test for a Controller class helps to test the logic within the Controller itself. Still, this won't tell you whether the REST endpoint this Controller provides actually responds to HTTP requests. So you move up the test pyramid and add a test that checks for exactly that - but nothing more. You don't test all the conditional logic and edge cases that your lower-level tests already cover in the higher-level test again. Make sure that the higher-level test focuses on the part that the lower-level tests couldn't cover. И тут мы получаем уже пространство для холивара про дефиниции, потому что: Два теста (на контроллер и на REST API вокруг этого контроллера) могут использовать сильно дублирующуюся кодовую базу. Но при этом объект тестирования у них разных, скоуп тестирования у них разный и, тащемта, даже инпуты и аутпуты у них будут разные. В обоих случаях у тебя будет какой-то процент тестов, которые можно реализовать и там, и там, а так же наборы тестов, которые можно реализовывать только на одном конкретном уровне. Писать тесты на логику контроллера, используя для этого REST API - так себе план. Писать функциональные тесты на REST API, включающие в себя логику контроллера (но не ограничивающиеся оной) - более хороший план. При этом эти тесты не смогут полностью дублирвоать тесты на контроллер (и тем более будут плохой заменой оным).

Благодарю! @azshoo

Ну пример с контроллером у него так себе) Сложность написания и время работы тестов на контроллер и на эндпоинт практически одинаковая, поэтому обычно можно обойтись только компонентными тестами на эндпоинт и не строить пирамиду на ровном месте А вот валидация веб-форм - это уже поинтереснее. Можно тестировать валидацию на уровне юнит тестов в JS, можно на уровне е2е тестов в браузере, плюс юнит и е2е валидации на бэке. Итого - 4 уровня, на которых можно написать тесты на одну и ту же логику, и каждый уровень имеет свои минусы. Потому что надеяться на то, что девелоперы покрыли все сценарии валидации юнитами и не похерили эти юниты - такое себе, но писать е2е тесты на валидацию в браузере - очень дорогое удовольствие

Со мной, наверное, что-то не так, но я правда не представляю, зачем в описанной ситуации писать подробные тесты на валидацию через E2E. За исключением ситуации, когда ни на фронте, ни на бэке тестов нету от слова совсем. Проблема "не похерили тесты" решается через codecov и принудительное ревью от QA при изменении тестов. Но да, я не работаю в командах, где у куак нет доступа к коду, поэтому в моём уютном мирке пирамида нормально работает.

>решается через codecov Ну, тот же сонар не умеет показывать reduced coverage, а переезжать ради этого на codecov не каждый согласится >принудительное ревью от QA при изменении тестов Звучит красиво, но на деле очень трудозатратно, когда ты единственный тестер на 5 девелоперов и они херачат код 24/7. Ну и самый серьезный аргумент для меня - каждый проект рано или поздно проходит стадию глобального рефакторинга, при котором выпиливается большинство юнит тестов, и если нет качественных компонентных или е2е тестов, то про фичу могут тупо забыть и целиком выпилить. В таких случаях black box тесты максимально себя оправдывают