Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Пытаюсь свести у себя в голове воедино информацию по тестированию, возник вот какой вопрос: а сколько нужно тестировать? Какие-то есть готовые рекомендации?
Попробую пояснить на конкретных примерах.
Пример 1.
Есть сайт-лендинг из одной страницы. На странице какой-то текст, т.е. контент полностью статический.
Пример 2.
Есть сайт-визитка из трёх страниц: заглавная, страница "контакты" и страница "о нас", все страницы - статический html.
Пример 3.
Тот же самый сайт, что и пункт 2, но на сайте есть страница "новости" (точнее две - news/all и news/view/{id})
Новости заполняются админом в sleeping owl.
Внутреннее устройство - таблица news в базе mysql (три поля: дата, заголовок, текст), модель Eloquent, один контроллер NewsController и одна секция.
Какие тесты нужно написать для приведённых типовых примеров?
Не в сети
Мастер 
Есть 3 вида тестов, остальное - их комбинация.
юнит тестирование, функциональное и приемочное.
юнит тесты - это тестирование каждого метода, перебор всевозможных комбинаций аргументов метода и сравнение с ожидаемым результатом. Тестирование маленьких блоков.
функциональные - похоже на юнит, за исключением того, что тестируется какой-то комплексный механизм. По типу - в таблицу А записали данные, запустили команду, результат должен оказаться в таблице Б и Ц.
приемочные - это тестирование веб-интерфейса (selenium/phantomjs/etc..)
Можно заметить, что юнит тесты и функциональные похожи между собой, ведь и то и то тестирует код.
Но, есть концептуальная разница. Юнит тесты просто говорят, что код - не падает с ошибкой (работает). Функциональные тесты говорят - что код работает правильно.
Да, выходит, что юнит тесты не так уж и важны, как функциональные, и это правда.
Однако, если в твоем коде зароется баг, найти его по юнит тестам - дело 1 минуты, в тоже время как по функциональным - придется инспектировать весь код.
Хорошим результатом считается - 75% покрытия кодам тестами (чисто мое имхо).
Посчитать покрытие может phpunit.
Папки vendor/* исключаются из подсчета.
codeception - хороший пакет для тестирования php приложений, который из коробки предоставляет все 3 вида тестов.
По поводу необходимости и достаточности покрытия тестами - все индивидуально к каждому проекту, в зависимости от сложности, доступного времени и т.п.
Кстати, интересная особенность, что идеал в тестах, это отнюдь не 150% покрытие, ибо каждый тест усложняет внедрение, да и поддержку в целом, новых фич в проект.
Идеал тестирования - это баланс, как золотое сечение, которое для каждого проекта свое.
Какие тесты нужно написать для приведённых типовых примеров?
Начинай с кор фич, заканчивай малым.
Я, в силу своей самоуверенности, не написал бы ни одного теста для твоих трех примеров выше 
P.S. Для всех, кто ни разу не писал тесты и думает, "а че там писать, сейчас быстро ворвусь" - вы неприятно удивитесь, что написание тестов - это совсем другой мир, со своими проблемами, и скорее всего (раз вы никогда не писали тесты) - окажется, что ваш код то и невозможно покрыть тестами.
Попробовать написать тесты для своего кода должен каждый разработчик.
Изменено covobo (18.09.2017 15:22:57)
Не в сети
Спасибо за помощь, но написанное -- не совсем то, что мне нужно. Теорию я читал (допустим раз, два, три), разницу юнит-тестов от функциональных понимаю и в курсе про TDD. Слышал, что тестировать надо не всё.
В сухом остатке для меня полезного было лишь "все эти примеры тестировать не нужно", а можно эту мысль развернуть подробнее?
Допустим, в первом примере тестировать юнитами мало чего можно. Наличие текста на странице -- это функциональный текст, допустим, проверить наличие правильного телефона в шапке. А юнитами что тестировать, разве что '/' отдаёт 200 OK.
Во втором примере нужно ли тестировать роутинг, что есть определённые страницы '/contacs' и что отдают 200 OK.
А в третьем случае что на практике нужно из этого?
И если допустим, во всех этих трёх примеров не нужно ничего тестировать, то может быть приведёте пример сайта, начиная с которого уже пора бы фиксировать тестами функциональность и проверять юнитами отдельные звенья? Как насчёт такого примера:
Пример 4. На сайте есть заглавная страница, страница '/home' (должна быть видна только залогиненным пользователям) и страницы '/login' и '/register'.
Здесь уже что-то нужно тестировать или всё ещё нет?
Изменено aksis (18.09.2017 16:25:01)
Не в сети
Мастер Твои примеры слишком простые и "нафиг оно надо тестировать".
Собственно, из-за этих примеров ты и сам не можешь понять, что надо покрыть тестами, ибо мысль о том, что этот функционал надо покрыть тестом, как правило, навязывается сама.
Допустим:
Ты написал приложение, веб-сайт, который представляет из себя калькулятор с работой произвольной длины чисел, вплоть до дециллиона.
Юнит тестами надо покрыть саму механику работы чисел.
Например: Преобразование из строки в нужную структуру данных, всевозможные арифметические операции и их приоритеты. Юнит тесты должны сказать, что твой код - не падает с фаталкой.
Функциональным тестом ты покрываешь что-то комплексней, например: что если запросов слишком много, предусмотренный твой механизм распределения нагрузки, например поставка задачи в очередь и последующая отправка результата на эмайл, будет работать.
Приемочным ты покрываешь: Что страница отдает 200, что на ней есть калькулятор, что если что-то поклацать и нажать на кнопку "результат" - появится результат (т.е. инспектируешь html код).
Не в сети
Мастер Пример 4. На сайте есть заглавная страница, страница '/home' (должна быть видна только залогиненным пользователям) и страницы '/login' и '/register'.
Да, можно покрыть это приемочным тестом.
Есть сайт-лендинг из одной страницы. На странице какой-то текст, т.е. контент полностью статический.
Достаточно просто мониторить какой нибудь тулзой не отвалился ли сайт.
Есть сайт-визитка из трёх страниц: заглавная, страница "контакты" и страница "о нас", все страницы - статический html.
Доступность всех страниц тузой (200 статус код)
Пример 3.Тот же самый сайт, что и пункт 2, но на сайте есть страница "новости" (точнее две - news/all и news/view/{id})Новости заполняются админом в sleeping owl.Внутреннее устройство - таблица news в базе mysql (три поля: дата, заголовок, текст), модель Eloquent, один контроллер NewsController и одна секция.
Юнит тестами здесь можно покрыть что-то, только если ты написал какие-то классы прослойки или другие маленькие блоки.
Функциональный тест - что валидация срабатывает, что она не перестала выкидывать exception.
Приемочным - можно написать полный сценарий, который добавляет пост, а потом ищет его на главной.
Грань между юнит тестом и функциональным очень скользкая, лично я редко пишу юнит тесты, в основном - функциональные.
Изменено covobo (19.09.2017 10:55:05)
Не в сети
Ты написал приложение, веб-сайт, который представляет из себя калькулятор с работой произвольной длины чисел, вплоть до дециллиона.
Это очень хитро подобранный пример )) Говорит правильные вещи: нужно сконцентрироваться на тестировании бизнес-логики, доменной модели. Только в laravel нет доменной модели и нет явной бизнес-логики, есть паттерн active record и нет никакого движения в сторону DDD. И поэтому пример подбирается такой, где нет логики сохранения в базу, соответственно нет навязыванию стиля active record, а есть объект калькулятор, ядро домена, ядро логики.
Это всё ж не типовой CRUD на примере entity новостей, репозитория и т.п.
Не в сети
Мастер
Тестировать типовой круд — нафиг.
Ведь, обычный action update выглядит так: $post->fill($request->all())->save();
Каждый из трех вызываемых методов протестирован фреймворков (я надеюсь), поэтому — писать тест на такой эндпоинт не имеет смысла.
Но, имеет смысл писать тест, если есть какая-то валидация.
Типовые вещи вообще нафиг тестировать.
Либо проект слишком простой, либо сложный и руки на написание тестов для таких простых вещей как простой udpate не дойдут никогда, ибо, написать тесты и на сложные кейсы достаточно сложно и долго, а их много.
Что можно подумать о человеке, который написал тест для этого? (не имя никакой логики на уровне бд, типа тригеров и on update cascade)
[code]
$post->fill($request->all())->save()
[/code]
Изменено covobo (22.09.2017 22:01:27)
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)