TDD: При тестировании ReST API Controller целесообразно тестировать все действия (создание, обновление, получение, удаление и т. Д. c) в одном тестовом файле? - PullRequest
0 голосов
/ 27 января 2020

Это явно практический вопрос. Мудрость Inte rnet предлагает логически организовать тесты на ремонтопригодность. Когда дело доходит до ReST API Controllers, можно включить все интеграционные тесты для всех действий контроллера в одном файле.

Предполагая, что у нас есть 4 действия CRUD на контроллер со средним числом 6 тестов на действие, которое мы связаны в итоге не менее 24 тестов в одном файле. В веб-серверах промышленного уровня я подозреваю, что это число увеличится еще больше.

Дело в том, что эти действия, даже если они являются частью одного класса (контроллера), являются сложными и ортоканоническими (разные ресурсы / Артефакты / макеты, необходимые для тестирования каждой группы и т. д. c).

Мне трудно прийти к соглашению, что все эти тесты должны быть помещены в один файл, учитывая тот факт, что они тестируют почти совершенно разные вещи и могут быть размещены в 4 отдельных файлах. Разве это не более соответствует духу TDD в конце концов?

Неужели моя интуиция неуместна?

1 Ответ

1 голос
/ 28 января 2020

Ничто не мешает вам организовать ваши тесты любым способом, который имеет смысл для вашего проекта.

Inte rnet Мудрость не имеет к этому никакого отношения, делай то, что работает для тебя. Вы хотите один тестовый файл для каждого метода? Тогда сделай это.

Где ваши тесты живут гораздо менее важно, чем то, что вы на самом деле тестируете и как.

Только одна предостережение, я видел, как люди проводят много времени и тестируют совершенно неправильные вещи.

Давайте создадим контроллеры для вызова методов из них (не, это признак действительно плохого SO C), давайте посмеемся над тем, кто что знает.

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

В остальном, я буду придерживаться интеграционных тестов, вызывать ваши конечные точки, как это делал бы обычный пользователь, и это в основном означает интеграционное тестирование. Используйте что-то вроде Postman для организации наборов тестов.

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

...