Pull to refresh

Comments 9

Молодцом. Только пара замечаний по терминологии:


  1. Настоящие репозитории в связке с AR (Eloquent) невозможны — уже обсуждалось не раз. Любые репозитории с AR — это на самом деле сервисы или просто макросы запросов. За исключением тех случаев, когда AR используется как мета-маппинг для DM (Analogue ORM, например).


  2. Сервисов нет из коробки потому, что это слишком абстрактное понятие. Настолько абстрактное, что его даже абстрактным классом или интерфейсом не описать.


Спасибо. Я согласен, что это не настоящие репозитории. По сути, я 2 Namespace использую. В один складываю бизнес логику и тестирую. В другой работу с Eloquent и не практически никогда не тестирую. Как раз поэтому я и сделал сноску о моей терминологии и что «академически» это не верно называть репозиториями.
Тест лучше писать до написания кода. Так больше контроля во время разработки.

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

Подход TDD имеет место быть. Я делюсь своим опытом. У меня пока нет понятного опыта работы с TDD, но хочу попробовать в будущем детальнее посмотреть сюда.


Умение составлять тест-кейсы и задавать вопрос «что именно я хочу протестировать» помогает снизить риски пропустить ошибку. TDD подход не исключает этих рисков. Я бы даже добавил, что 100% coverage через TDD не является гарантией отсутствия багов.


Также рефактор кода во время написания тестов для меня является «нормальной» практикой. Я это делаю достаточно часто.

Подход TDD имеет место быть. Я делюсь своим опытом. У меня пока нет понятного опыта работы с TDD, но хочу попробовать в будущем детальнее посмотреть сюда.

Понимание плюсов TDD приходит с практикой. Вы правильное делаете, что смотрите в эту сторону.

Рекомендую посмотреть для общего развития, если не видели "Зачем и как писать качественные Unit-тесты (Алексей Солодкий / Badoo)"
«Спасибо» за минусы, кто поставил :) На самом деле почитайте принцип TDD. Там как раз и говорится о том, что тест сначала, код потом. По сути, TDD говорит о том, что «вы» знаете что должен вернуть метод при определенных входящих аргументах. То есть, знаете как должен будет работать тестируемый метод. Если этого не знаете, то в общем смысле — не знаете мини-задачу, которую решаете.
Ничего не сказано про тестирование моделей. А ведь туда уходит часть логики связанная именно с моделью: асессоры, мутаторы, кастинги ($casts) определенных полей, наличие полей в $fillable, relations и т.д.

Дополню тему этой ссылкой: 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 есть преимущество: больше слов помещается в ширину экрана.

Only those users with full accounts are able to leave comments. Log in, please.