#ruby_on_rails #веб_программирование #test_driven_development
Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
Закрыт 3 года назад.
Никак не могу понять, как TDD сумел обрести такую популярность. Почему? Потому что
я считаю это максимально иррациональным подходом к разработке:
Ты должен написать тест, который заведомо провалится.
Трата времени. Ты не написал ни одной строчки кода, зато написал 20 строк кода, чтобы
убедиться в том, что то, чего ты не написал, не работает.
Ты должен написать тест, который реализует твои мысли относительно того, как это
должно работать.
Трата времени. За то время, пока ты реализовывал свои мысли в строках теста, ты мог
реализовать свои мысли строками кода.
Ты должен написать код так, чтобы он прошел написанный тест.
А в это время ты уже мог заниматься рефакторингом написанного кода.
Рефакторинг.
Еще одна особенность. Как мы знаем, веб-разработка предполагает разработку того,
с чем конечный пользователь будет взаимодействовать через браузер. Подход TDD предполагает
максимальное абстрагирование от браузера и использование для проверки работоспособности
кода только командную строку. Чувствуете этот запах? Так пахнет логика.
Чтобы мои слова не звучали необоснованно, я приведу вам пример того, как я пытался
освоить данную ветвь.
Изначально я знал, что люди с нелюбовью относятся к имеющемуся в rails стандартному
test-фреймворку. И я также прекрасно знал, что подавляющее большинство предпочитает
ему использование Rspec.
Первым делом я, конечно же, решил ознакомиться с документацией по Rspec. По первой
же ссылке в гугле я попал на эту страницу. Красивый landing-page с кучей видео разряда
ни о чем. Окей, почитаю документацию, решил я. Абсолютно ничего дельного эта страница
мне не принесла. Лишь внизу красовалась ссылка на какой-то Relish. Что это такое и
каким боком оно относится к Rspec - непонятно. Ладно, переходим.
Только оттуда с непримечательной ссылки Rspec-core (догадайся 2) я попал на нечто,
что хоть как-то похоже на то, что я ищу. Какие-то примеры кода. Да, сразу код. Не понятно,
как установить, какая структура должна быть у папок, как нужно именовать файлы, как
запускать - ничего.
Спустя день, перелопатив кучу инфы по этому поводу, я узнал, куда стоит класть файлы,
как именовать папки, что require-ить, какие методы использовать (базу). Помогли мне
в этом довольно полезные скринкасты (на которых, кстати говоря, было полностью разработано
приложение без использования тестов, а тесты писались "в обучающих нас целях", когда
все уже заведомо работало так, как надо, и в данном случае тесты подгонялись под код,
а не наоборот (как это предполагает TDD), что еще раз доказывает нам ненадобность использования
оного). Не было ни какой конкретной инфы (в виде гайда, как это сделано в случае rails,
или хотя бы общей спарвки) ни на хабре, ни на railscasts (даже с pro-подпиской), на
которых R. Bates в своей привычной манере "проскакал" по верхам, показав типичный пример
из ряда "сделайте так-то, у меня получилось так-то, на это до свидания".
Садимся писать. Создаем приложение, устанавливаем необходимые гемы, пишем. Решил
я начать по-порядку. Роутинг. Написал тесты, которые должны были заведомо провалиться.
Провалились не тесты, а сам Rspec. Оказалось, ошибка синтаксиса (правильно, я же еще
должен знать, как писать). Тратим время на поиск примеров. Реализуем. Тесты провалились.
Реализовываем код (а что там реализовывать? Написал необходимые мне пути). Тесты прошли.
На все про все у меня ушло около 3-х часов. За это время я бы успел реализовать не
только логику routing'а, но и логику модели и отчасти каких-то контроллеров.
Решил заняться написанием контроллеров. Опять уперся в банальное незнание и неумение
пользоваться новым инструментом. Как человек наученный каким-то опытом, не стал проклинать
в этом всех и вся, а просто полез в документацию. Окей, гугл, "rspec controller". Это
все, что нам предоставляет, насколько я понял, официальная документация. Опять же этот
Relish. На этом этапе я матюкнулся, послал все к чертям и решил немного отдохнуть.
Теперь, отдухнув, пишу сюда. И нет, пишу я не с целью выговориться или в очередной
раз, но уже на публику, проклясть этот TDD, а разобраться.
Да, даже несмотря на все мои неудачи, я хочу разобраться, во-первых, в том, почему
же этот TDD так популярен? Почему все "настоятельно рекомендуют закрыть браузер и написать
парочку тестов", когда можно спокойно (и даже более полезно для себя с точки зрения
психики) обойтись простым визитом на localhost:3000? Что движет всеми теми, кто так
усердно (если такие вообще есть, и это не просто показуха) использует TDD? И самое
главное: в чем опасность отказа от этого подхода? Может ли отказ как-то сказаться на
твоем резюме или в поиске работы?
Если есть действительно весомые аргументы против моей точки зрения, то прошу подкрепить
свой ответ ссылками на обучающие материалы по этой теме (желательно от и до, подкрепленные
real-life примерами и охватывающие хотя бы половину из того, с чем можно столкнуться
при реальном использовании).
Спасибо тем, кто осилил. Заранее извиняюсь, если это оскорбило чьи-то чувства. Предполагается,
что все, что написано выше - ИМХО.
Ответы
Ответ 1
Здесь есть три составляющие: Во-первых, сами тесты. Они нужны, в первую очередь, чтобы при дальнейшем изменении приложения не ломался старый функционал. Понятно, что, если приложение достаточно маленькое, быстрее и приятнее прокликать всё руками. Но с каждой новой фичой такое прокликивание будет занимать всё больше времени. К тому же, какие-то кейсы могут быть забыты. Автотесты же помогают прогнать тесты быстро и минимизировать человеческий фактор. В итоге, появляется возможность использовать CI. RSpec, в основном, подразумевает написание модульных тестов. Однако можно использовать, например Cucumber - тесты больше похожи на привычное "прокликать". Но, при этом, сами сценарии тестов становятся сложнее, т.к. сразу нужно проверить гораздо больше кейсов. Во-вторых, TDD. Пожалуй, в рамках TDD тесты понятнее будет называть спецификациями (specifications, specs - в RSpec). По сути, это текст задания, написанный в понятном для интерпретатора виде. На сколько написание спецификаций до кода себя оправдывает - один из холиваров. В любом случае, автотесты нужны. А в какой момент их писать - решать тебе. Лично мне было сложно писать "test first" (да и "last") до знакомства с принципами SOLID. Но, теперь, как сайд-эффект, мне легче проектировать архитектуру классов. Специфика RSspec такова, что легче тестировать солидные классы. (Спеки для несолидных получаются длинные, с кучей стабов и моков.). Судя по статье в вики, не я один отметил этот эффект: Разработка через тестирование предлагает больше, чем просто проверку корректности, она также влияет на дизайн программы. Разработка через тестирование способствует более модульному, гибкому и расширяемому коду. В-третьих, RSpec. Как я уже говорил, это не единственный фреймворк для написание тестов. На сколько я понял, основные проблемы возникли именно из-за его незнания. Но это не делает его "плохим". Писать быстро на незнакомом фреймворке вряд ли получится хоть у кого-то. Да, написание тестов, как и любого другого кода, занимает дополнительное время. Но обычно, всё же, это не 3 часа вместо 15 минут. В твоём же случае, это были затраты на обучение а не написание. Кстати, я в первый раз вижу, чтобы тестировали роуты. Обычно не требуется покрытие всего кода тестами. Корректность части компонентов (например тех же роутов) будет очевидна из корректности остальных компонентов. Ну и на практике, TDD хорошо подходит для крупных проектов, в которых проектирование на должном уровне. Для стартапов, функционал которых не очень велик, зато очень часты изменения - может быть излишним. Для лендингов, весь бэкенд сводится к отправки email с введённым пользователем телефоном - тоже.Ответ 2
Надо понимать на что и как писать тесты, в каждом проекте может быть очень важный участок, внесение изменений в который очень критично - например модуль для подсчета денежной информации, так и участок менее важный - например ui админки сайта. А так, навскидку: Поддерживаемость - Тесты нужны, например, если вы собираетесь без боли рефакторить код, потом, через год, или не вы. Модульность, принцип единой ответственности - TDD вынуждает разработчика писать чище и проще, заранее придумывать апи, держать цикломатическую сложность в тонусе.
Комментариев нет:
Отправить комментарий