@JeanPaulBelmondo

Вопрос о тестах. Что вы об этом думаете?

Конкретно мой проект написан на Laravel, но большой роли это не играет думаю.

Вопрос:
нужно ли пытаться отвязаться от исходного кода проекта? например при тестировании api создания или удаления, нужны данные можно очень легко создать с помощь Model::factory()->make() (при условии что фабрики уже есть конечно же) и всё будет прекрасно работать.
$params = Model::factory()->make()->toArray();

$this->post('blablabla', $params)


мне же предлагают отказаться от фабрик и вручную все параметры заполнять
$this->post('blablabla', [
    'param1' => 'value',
    'param2' => 'value',
    'param3' => 'value',
    'param4' => 'value',
    'param5' => 'value',
    'param6' => 'value',
    'param7' => 'value',
    'param8' => 'value',
    'param9' => 'value',
])


вопрос - зачем?
главный аргумент, как я понимаю - это стабильность тестов и разговоры в стиле "а вот если фабрики удалят, а вот если будет рефакторинг кода, а вот если, а вот если".
но по-моему это какой-то бред и что-то неадекватное )

1) по-моему нет вообще ни одного сценария удаления фабрики (если она вообще была сделана), если уж удаляют фабрику, то наверное и тест api не нужен;
2) при рефакторинге кода тест можно сломаться точно так же и неважно статика у него в параметрах или что-то сгенерированное фейкером;
разве не так?
  • Вопрос задан
  • 106 просмотров
Пригласить эксперта
Ответы на вопрос 2
Проблема такого теста в том, что он тестирует сразу две вещи:
1. Что работает api
2. Что работает Model::factory()->make()->toArray(), которая генерирует аргументы для вызова api

От этого возникают следующие проблемы:
1. Без изменения кода api у тебя тест может неожиданно начать падать и наоборот.
Например ты поменял названия параметров. Тест зелёный, тк фабрика генерит параметры, а клиенты все теперь 400-е ошибки получают.
Контракт получается незафиксированный.
2. Ты не можешь при таком подходе нормально проверить негативный сценарий и граничные значения.
Чтобы их проверить - тебе всё также придётся отказаться от Model::factory()->make()->toArray() и составлять параметры руками.

Вообще, api-тесты часто пишут вообще без привязки к коду - при помощи сценариев для postman например.
Ответ написан
Комментировать
@jazzus
Фабрики уберут, Ларавел отменят, PHP закроют. Нужно срочно все изолировать пока лицензии не отобрали и не навязали принудительное обновление. Всё прячем в говнокод.. Ты можешь юзать сгенерированные данные, если логика теста это позволяет. и не toArray, а указать в структуре конкретного запроса. Если по счастливой случайности у тебя пока модель совпала с запросом, то это не значит, что фабрика/логика/модель не будут меняться и тесты не начнут неэффективно падать на пустом месте, тупо изза данных реквеста, которые ты не контролируешь. Нужна изолированность и точность. Минимум автоматизации и универсальности. Бд обязательно сносить перед каждым тестом (юзать трейт). Конечно, это если ты собираешься писать много тестов и нормально работать с ними (тдд например). Если 1 тест ради теста, шлепнуть пост запрос, то вообще все равно как его писать и поддерживать, можно смело генерировать структуру запроса из фабрики целиком или еще что-нибудь придумать.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы