Комментарии 10
Молодцом. Только пара замечаний по терминологии:
Настоящие репозитории в связке с AR (Eloquent) невозможны — уже обсуждалось не раз. Любые репозитории с AR — это на самом деле сервисы или просто макросы запросов. За исключением тех случаев, когда AR используется как мета-маппинг для DM (Analogue ORM, например).
Сервисов нет из коробки потому, что это слишком абстрактное понятие. Настолько абстрактное, что его даже абстрактным классом или интерфейсом не описать.
Написание тестов после написания кода грозит тем, что требования теста подгоняются под готовый код. И как следствие, можно пропустить кейс с ошибкой в коде. Которая проявится потом.
Подход TDD имеет место быть. Я делюсь своим опытом. У меня пока нет понятного опыта работы с TDD, но хочу попробовать в будущем детальнее посмотреть сюда.
Умение составлять тест-кейсы и задавать вопрос «что именно я хочу протестировать» помогает снизить риски пропустить ошибку. TDD подход не исключает этих рисков. Я бы даже добавил, что 100% coverage через TDD не является гарантией отсутствия багов.
Также рефактор кода во время написания тестов для меня является «нормальной» практикой. Я это делаю достаточно часто.
Подход TDD имеет место быть. Я делюсь своим опытом. У меня пока нет понятного опыта работы с TDD, но хочу попробовать в будущем детальнее посмотреть сюда.
Понимание плюсов TDD приходит с практикой. Вы правильное делаете, что смотрите в эту сторону.
Рекомендую посмотреть для общего развития, если не видели "Зачем и как писать качественные Unit-тесты (Алексей Солодкий / Badoo)"
Дополню тему этой ссылкой: github.com/framgia/laravel-test-guideline
По моделям там вполне исчерпывающе.
Вижу, что используется camelCase, но на мой взгляд, читается он хуже, чем snake_case, особенно в feature тестах, где тестим какую-то бизнес-логику. Авторы Laracasts используют snake_case.
Сравним:
public function test_if_total_spent_kcals_changed_after_adding_exercise() {}
public function testIfTotalSpentKcalsChangedAfterAddingExercise() {}
Вроде есть PSR-2, но по-моему очевидно, что для длинных названий методов тестов лучше не следовать camelCase.
Я стараюсь не тестировать фреймворк своими тестами. Может быть и есть некоторый смысл в тестах состава полей в переменой fillable, но мне кажется это не оправданным.
У меня в моделях нет бизнес логики, я все выношу ее в сервисный слой. Поэтому сами модели у меня достаточно легкие.
Писать тесты на связи — можно, конечно, но зачем? У вас были случаи, когда эти тесты вам помогли? Тесты ради тестов или coverage никому не нужны.
Насчет стиля именования тестов.
Вам очевидно одно, мне другое. Авторы laracast и ряда пакетов используют snake_case, авторы Laravel и ряда пакетов следуют PSR-2 и используют camelCase. В каждой команде есть свой style-guide написания кода. Это вкусовщина, а моя статья о другом. Давайте не будем отвлекаться и спорить о вкусах.
Как раз в случае длинных многословных имён у camelCase есть преимущество: больше слов помещается в ширину экрана.
Делать Mockery::close() в tearDownl в Laravel не нужно. Если посмотрите \Illuminate\Foundation\Testing\TestCase::tearDown, там уже есть вызов к Mockery::close()
Unit тестирование в Laravel