Проверка типов происходит самим фреймворком, на котором написан бэк. Вы можете единожды сделать проверку типов, убедившись тем самым, что она отрабатывает. Но ее не имеет особого смысла применять в чек-листе для каждого АПИ метода. Иначе мы каждый раз будет проверять работоспособность самого фреймворка по-сути.
Здравствуйте. Случай может произойти любой. Мы не можем гарантировать, что клиент ни отправит нам такой кейс, т.к вся основная валидация - это обязанность сервера. А на клиенте может произойти все, что угодно. Соответственно чем более полное покрытие мы будем иметь на конкретный метод, тем более полную картину получим: "а что у нас может пойти не так" и тем выше по итогу будет качество выпускаемого API метода.
Здравствуйте. В статье использован подход, который взят с реального проекта, в том числе и подход к написанию чек листов. Рекомендую не думать, что вы один используйте этот стек технологий. И не следует также обращаться на "ты". Давайте друг-друга уважать.
Очистка системы – хорошая практика. В данной тестовой апишке с точки зрения самих тестов, без очистки от запуска, отсутсвие самой очистки не создает проблем для самого процесса прогона тестов т.к в этих методах на нас не влияет состояние системы. Тут нет пользователей, состояние которых от запуска к запуску как-то бы влияло на тесты. Но повторюсь это актуально только в этой учебной АПИ. В реальных проектах хорошая практика производить очистку.
Есть еще один момент, когда мы производим очистку, мы каждый раз запускаем тесты, как правило, на идеально чистой базе, что немного оторвано от реальности т.к в боевых условиях как правило база нагружена и забита. Так что в каком-то аспекте прогнать тесты на нагруженной базе тоже неплохая практика. У меня на работе был такой случай, что на чистой базе тесты проходят хорошо, а на нагруженной была задержка транзакций, и сервер выдавал в ответе POST методов устаревшие состояния объектов.
Я соберу фидбэк по этой статье и думаю выпущу продолжение. Там мы рассмотрим аспекты очестки и другие моменты.
Проверка типов происходит самим фреймворком, на котором написан бэк. Вы можете единожды сделать проверку типов, убедившись тем самым, что она отрабатывает. Но ее не имеет особого смысла применять в чек-листе для каждого АПИ метода. Иначе мы каждый раз будет проверять работоспособность самого фреймворка по-сути.
Здравствуйте. Случай может произойти любой. Мы не можем гарантировать, что клиент ни отправит нам такой кейс, т.к вся основная валидация - это обязанность сервера. А на клиенте может произойти все, что угодно. Соответственно чем более полное покрытие мы будем иметь на конкретный метод, тем более полную картину получим: "а что у нас может пойти не так" и тем выше по итогу будет качество выпускаемого API метода.
Здравствуйте. В статье использован подход, который взят с реального проекта, в том числе и подход к написанию чек листов. Рекомендую не думать, что вы один используйте этот стек технологий. И не следует также обращаться на "ты". Давайте друг-друга уважать.
Curlify насколько я знаю конвертирует запросы в curl command. Не совсем понял вас, как это поможет воспроизводить тесты.
Очистка системы – хорошая практика. В данной тестовой апишке с точки зрения самих тестов, без очистки от запуска, отсутсвие самой очистки не создает проблем для самого процесса прогона тестов т.к в этих методах на нас не влияет состояние системы. Тут нет пользователей, состояние которых от запуска к запуску как-то бы влияло на тесты. Но повторюсь это актуально только в этой учебной АПИ. В реальных проектах хорошая практика производить очистку.
Есть еще один момент, когда мы производим очистку, мы каждый раз запускаем тесты, как правило, на идеально чистой базе, что немного оторвано от реальности т.к в боевых условиях как правило база нагружена и забита. Так что в каком-то аспекте прогнать тесты на нагруженной базе тоже неплохая практика. У меня на работе был такой случай, что на чистой базе тесты проходят хорошо, а на нагруженной была задержка транзакций, и сервер выдавал в ответе POST методов устаревшие состояния объектов.
Я соберу фидбэк по этой статье и думаю выпущу продолжение. Там мы рассмотрим аспекты очестки и другие моменты.
�