тупят по перформансу в кубернетесе и что нужно переписать его на golang ;)
2) вам общаться с этим API, клиентским приложениям общаться с этим API. Его реализация влияет очень на многое.
3) Вы реально думаете, что замочив сервис второго уровня, вы не пропустите баг в интеграции с ним? Вы можете сразу тестировать end2end и смотреть как сервисы дружат. А вот в случае с тестированием внешней интеграцией я думаю кейс с моками более удобоварим
4) СУБД влияет на то, как хранятся данные, как быстро их можно вытащить (странно если сервис с нагрузкой в 20000 rps будет ходить каждый раз в postgresql или mysql). Ну и тем более вам валидировать данные, которые попадают в эту базу.
5) Про кеширование кстати можно было бы еще спросить.
опять же это все не относится к вопросу "как вы будете тестировать сервис"
Спасибо) про ЯП это, кнч, мощно, но вопрос скорее был бы актуален если бы на стадии документации, еще до реализации его задавать. Если сервис написан то тестировать придется то что есть. С API вопрос тоже, мне кажется, влияет уже на какие-то технические аспекты, а по факту какое-бы API не было, нужно проводить контрактное тестирование, поправьте если ошибаюсь. 3) если я добросовестно замочил сервис и проверил все запросы и ответы своего сервиса и другой тестировщик добросовестно замочил мой сервис и проверил запросы ответы по спеке, то если убрать всякие непредвиденные обстоятельства, все должно быть при интеграции хорошо. Все предусмотреть, кнч, нельзя и от багов не спасет, но их будет меньше и разбираться че там не так тоже будет легче. 4) тоже похоже на техничнский вопрос, я так понимаю, все таки хотели услышать общую логику тестирования без подобных практических углублений. А может и нет)
Обсуждают сегодня