#testing #salesforce #apex
Вопрос:
Это не вопрос, касающийся кода/конкретного случая.
Я новичок в Apex и пытаюсь протестировать методы, которые выполняют выноски для внешних API. Я понимаю, что для тестирования этого метода мне нужно создать класс, реализующий HttpCalloutMock, и использовать его в своем тесте.
Тем не менее, я хочу знать: в тесте, когда я вызываю фактический метод, который я тестирую, происходит ли вызов API за кулисами? Или данные, которые я помещаю в макет, являются единственными данными, которые передаются?
(Я спрашиваю, потому что, если последнее, не означает ли это, что эти тесты крайне контрпродуктивны и не нужны?)
Ответ №1:
Фиктивные данные, которые вы предоставили в фиктивном классе, будут послушно возвращены. И да, это раздражает, двойная работа.
Но как еще это можно было сделать? Действительно вызов внешнего API может иметь плохие последствия (отправка «Моего потрясающего тестового заказа!!!1 один!одиннадцать» для производственной системы выполнения было бы катастрофой, особенно если вы делаете это несколько раз, потому что развертывание продолжало сбоить). И когда такой API выйдет из строя, и вам действительно, действительно нужно будет что — то развернуть в производстве-вы не должны быть заложником стороннего сервера, даже тестового.
Вместо того, чтобы ворчать, попытайтесь принять это. Да, это чушь собачья. Но это ваша возможность проверить, как ваш код обрабатывает различные выходные данные. Как он реагирует, когда ответ API «Внутренняя ошибка сервера HTTP 500», HTML вместо JSON или даже ответа нет, просто тайм-аут. Чем более прочным вы его сделаете, тем увереннее будете себя чувствовать.
Неужели это действительно так сложно? Соберите пару реальных сообщений и ошибок, удалите конфиденциальные данные, выполните какое-нибудь заявление о переключении «если номер учетной записи = 123, верните это, еще верните это», и все готово.
И да, это, по сути, означает, что вы сами реализуете логику третьей стороны. Но в любом случае, при разработке на основе тестирования вы в идеале должны были бы начать с фиктивного представления их сервиса, что-то, что достаточно близко к «контракту» API, который у вас есть. И в качестве бонуса — вы можете кричать на них, когда что-то внезапно ломается, и вы можете доказать, что это не было изменением с вашей стороны.
В конце концов, это не слишком отличается от совместной работы с другим разработчиком SF. «Хорошо, я сделаю часть пользовательского интерфейса, вы сделаете часть apex, вот интерфейс данных, который мы обещаем использовать, увидимся через 1 неделю». Насколько ты можешь доверять этому парню, а? 😉
Комментарии:
1. Спасибо. Я, честно говоря, не понимаю, как этот тип тестирования может быть полезен, но, возможно, я просто не понимаю тестирования (у меня очень мало опыта в этом). Вы только что доказали, что дважды написали одну и ту же строку в своем наборе тестов. Я предполагаю, что у вас есть точка зрения о 500 ошибках.
2. Я думаю об этом так же, как и обо всех других данных, которые вы создаете для своего теста. Речь идет не о тестировании фактических выносок, а о тестировании того, как ваш код работает с возвращаемыми данными. Та же концепция, что и при создании тестовых данных SF.