Хорошие практики тестирования в Laravel проектах?

Question

[Nikolino]

Поделитесь пожалуйста вашими best practices по работе с тестами, особенно когда их много. По структурированию, именованию тестов и т. д.

Вопрос, возможно, выходит за рамки Laravel.
Из коробки фреймворк создает две директории: Feature и Unit.
Feature это нечто высокоуровневое. В видео Laracasts Jeffrey Way зовет их интеграционными, кто-то зовет их приемочными, где-то обзывают их smoke-тестами. У всех свои подходы и фреймворк в этом не ограничивает.

Создаете ли вы подпапки в Feature директории, например Controllers, Endpoints, Jobs...
Используете ли в Feature(и Unit) тестах несколько assert'ов или разбиваете на разные тесты для читаемости?

Как вы именуете unit-тесты?
Используете ли camel-case или через нижнее подчеркивание?

Ответы желательно поподробнее, чем: "Дело хозяйское. Как тебе удобно, так и делай". Оно и так понятно, что можно по-разному.

Answer 1

[Alex Wells]

Feature - это end-to-end тесты. Ты берешь данные, отправляешь на эндпоинт и проверяешь ответ/статус выполнения задачи. Из этого следует, что никаких под-директорий там быть не может - максимум одна для API, одна для Web, и, если сильно хочется, то одна для CLI. В таких тестах НЕ должно быть моков, подмены зависимостей или чего-либо еще, что мешает полному тестированию эндпоинта от начала и до конца.

Обычно пишу по одному на каждый эндпоинт, типа GamesListTest для /api/games.

Unit - юнит тесты. Должны тестировать один класс и мокать остальные зависимости. Тут можете тестировать отдельно контроллеры, джобы, репозитории, сервисы и что-либо еще, что вам вздумается. Все депенденси этих классов нужно подменять и проверять входные аргументы (как можно тщательней, mockery + hamcrest-php).

Тоже обычно по тесту на класс, то зависит от размера класса, о котором идет речь, и сложности его методов.

Всегда использую snake_case - так читаемей. assert'ов может быть хоть миллион - за этим вообще не слежу. Разбиваю тесты на методы чисто по логике и нужде - как проще, так и делаю. Лично у меня тесты лежат в "модулях", а не в /tests, но дефолтная структура - неплохой вариант для начала.

Comments

[Nikolino]

Alex Wells
"Обычно пишу по одному на каждый эндпоинт, типа GamesListTest для /api/games"

То есть, для проверки эндпоинта, который сохраняет данные в базу(добавляет новую игру) вы создадите еще один тест класс? И для обновления данных об игре еще один?
Или тестируете все связанные с играми эндпоинты в одном классе?

[Alex Wells]

Nikolino, первый вариант. Сохраняет - один, вытягивает - второй, обновляет - третий.

У тестов, по сути, нету никаких правил. Такой класс может состоять из одного теста, а может из сотни - проблемы я в этом не вижу.

[Nikolino]

Alex Wells, ваш вариант, пожалуй, лучше. Так как, если несколько разработчиков на проекте будут наваливать тесты в один класс, то вскоре сложно будет понять написан ли тест для какого-то случая и есть вероятность, что два разных разработчика напишут по сути одинаковый тест два раза, потому, что весь класс читать лень)

[Alex Wells]

Nikolino, ну да, но это не только тестов касается)

Answer 2

[Евгений Ромашкан]

Для меня в идеале структура папки unit идентична src, в src разбиение по функционалу типа /product /cart и т.п., никаких Controllers/ и Models/ со свалкой всех контроллеров и и т.п.

Comments

[Nikolino]

Допустим у вас есть ProductCartService, в какую папку вы его засунете, в /product или /cart? :)

Почему плохо засунуть его в папку Unit/Services, а джобы в папку Unit/Jobs и т.д.?

[Максим Федоров]

Nikolino,

Почему плохо засунуть его в папку Unit/Services, а джобы в папку Unit/Jobs и т.д.?

Ох, в длинную историю вы затягиваете собеседника

[Евгений Ромашкан]

Nikolino, Если у меня есть ProductCartService что-то уже пошло не так :)))
Не должно быть таких сервисов, из его названия не понятно что он делает. Сервис добавления продукта в корзину будет в /cart/, т.к. происходит изменение корзины а не продукта.

Папки services/ jobs/ будут разрастаться бесконечно, как бы мы не дробили фичи.

Могу посоветовать глянуть этот гист - https://gist.github.com/fesor/76d39b19b18f7103a7c0...

[Nikolino]

Евгений Ромашкан, не помню точно, как оно в Symfony, но судя по Gist'у, у Laravel и Symfony подходы в структуре отличаются как раз таки в том, что в Laravel разделение по сущностям приложения (или фреймворка): то есть Models, Controllers, Jobs, Requests(Validators) и т.д., а уже внутри сущностей приложения имеем сущности бизнес-логики, то есть внутри Controllers имеем ProductController, UserController, CartController и т.д.

А в гисте описан обратный подход, когда самый высокий уровень папок это сущности бизнес-логики: /cart, /product и т.д., а уже внутри них actions, models и т.д.

Понятное дело, что и подход в тестах тогда будет отличаться при различии в подходах всей структуры проекта.
Но превращать Laravel в Symfony и создавать папки согласно бизнес логике (внутри папки /app, или /src, если по-вашему :)) это то еще извращение.

Наверное нужно опробовать и то и другое, тогда прозрачнее станет, какой в конечном итоге удобнее.

[Евгений Ромашкан]

Nikolino, В симфони точно так же по дефолту структура с entities и т.п. на верхнем уровне )
Вот как раз не знаю как в Ларе(хотя знаю что люди и в Ларе эти папочки убирали), а в Симфони они просто удаляются и создаётся та структура что вам нужна.

Ну и даже на проектах без разделения по фичам на верхнем уровне, структуру папочки tests/unit мы держали идентичной src/