https://www.eviltester.com/page/books/automating-testing-api-casestudy/

https://www.amazon.com/s?k=api+testing&ref=nb_sb_noss_2



Также рекомендую материалы от COMAQA:
https://www.youtube.com/results?search_query=comaqa+api+testing

Why not? Для себя написать-замокать.

Есть случаи когда АПИ на Спринге, и для тестов
а) эндпойнты и данные читаются в спринговом коде
б) переиспользутся DTOшки от спринга.

"Вообще" можно и не заглядывать, но бывает и польза от заглядывания и переиспользования.

Другого - это какого?) Что такого в качестве именно API, что нужно внезапно перейти к копанию в потрохах?)

Да. А можно попросить разработчиков замокать. И ниже - тоже да. Можно, но не нужно, особенно в контексте. А @Cadabrum, как всегда, предлагает на запрос новичка "дайте книжку попроще" пойти копаться в потрохах. Хотя ни выгоды, ни мотивации, ни денег новичок из этого не извлечёт.

Ну вообще-то просьба была не книжку по-проще, а что-нибудь по-солиднее статей для начинающих. А я собственно и подвожу к тому, почему таких материалов очень мало, либо их вообще нет. Чтобы понимать, как составить качественное покрытие, или даже прост почему кейс именно такой, нужно знать как внутри система работает. Там, если утрировать, может быть кейс " отправьте 4321", а ты даже не поймешь почему именно 4321 а не  1234, так как для тебя эти значения ничем не отличаются, цифры и цифры. И почему на другом стеке, API внешне выглядит точно так же, скажем, /login, юзер, пароль в параметрах, а этот кейс уже будет бесполезным или избыточным.

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

А если статья просто введение в тестирование API, там на бананах - отправили корректный юзернейм, получили токен, некорректный - forbidden, поздравляю, мы написали тесты, теперь вы можете писать свои :)

Опять же, я не утверждаю что новичку нужно сразу изучать всё возможные стеки от и до. Это направление, в сторону которого можно копать, потихоньку разбирая фичи и их реализацию. Начать от базовых тем вроде устройства протокола http и постепенно осваивать остальное.

Не буду показывать пальцем, но от синьор автомейшенов вполне могут ожидать знания спринга в объёмах написания простенького апи. Это факт реальности который некоторые мои знакомые встречали.

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

Да блин вполне себе под нужды автоматизации webhooks приходилось писать на обработку prs.  Чтобы тесты запускать на разные условия. И еще тестовые окружения должны были по событию устанавливаться.

Когда такие дискуссии читаю на тему глубины вхождения в темы, вспоминаю одну историю. Мальчик пишет в детский журнал - дорогая редакция, я очень люблю шахматы и научился играть. Правда конем я пока ходить не умею. Найдите мне, пожалуйста, гроссмейстера, чтобы я мог с ним играть. Ответ редакции - дорогой мальчик, как только мы найдём гроссмейстера, который не умеет ходить конем, так сразу свяжемся с тобой. Мне лично не хочется быть не умеющим играть конем среди гроссмейстеров.

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

Еще бы время на все это!

Без этого никак, 15-20 минут в день концентрированно лучше, чем никак

учиться просто чтобы учиться? нуну… любые знания и навыки без практики атрофируются очень быстро (пойду протру пыль с сертификата по win2003 и 1C)

15-20 минут нужно только для того что-бы голову переключить из текущих задач
для полноценного освоения нужно пару часов в день как по мне

Учиться и сразу применять эти знания. Чтобы освоить что-то новое нужно делать что-то новое и ввязываться во всякие необязательные активности, да.

Я такую ошибку делал, хотел заниматься 2 часа в день, а поскольку 2 часа не мог найти, то не делал ничего в итоге

период полураспада знаний +1. но глубоко изучать инструменты все равно надо. просто адекватно подходить ко всему.  И там человек в начале дискуссии вроде спрашивал про начальные знания. лезть в кишки сразу имхо трата времени. тем более QA/Testers,  наша профессия все таки больше про ширь чем про глубь (и ширь на первом месте не случайно)