Ruby on Rails - зачем использовать тесты?

Question

Я не совсем понимаю, для чего нужны различные тестовые устройства в Ruby on Rails. Я использую фреймворк около 6 месяцев, но я никогда не понимал его тестирование. Единственное тестирование, которое я использовал, - это JUnit3 на Java, и это ненадолго.

Все, что я читал об этом, просто показывает проверки. Разве проверки в рельсах не должны работать? Это больше похоже на тестирование фреймворка, чем на тестирование вашего кода. Зачем вам нужно проверять валидации?

Кроме того, тесты кажутся очень хрупкими к любым изменениям в вашем коде. Поэтому, если вы что-то измените в своих моделях, вы должны изменить свои тесты и приспособления для соответствия Разве это не нарушает принцип СУХОГО?

В-третьих, написание тестового кода занимает много времени. Это нормально? Разве не было бы быстрее обновить мой браузер и посмотреть, работает ли он? Мне уже нужно поиграть с моим приложением, чтобы посмотреть, правильно ли оно работает, и убедиться, что мой CSS не взорвался. Почему ручного тестирования будет недостаточно?

Я задавал эти вопросы раньше, и я не получил ничего, кроме "автоматизированное тестирование автоматизировано". Я достаточно умен, чтобы выяснить преимущества автоматизации задачи. Моя проблема в том, что затраты на написание тестов кажутся нелепо высокими по сравнению с преимуществами. Тем не менее, любые подробные ответы приветствуются, потому что я, вероятно, пропустил одно или два пособия.

Answer 1

Не должны проверки в рельсах просто работают? Это больше похоже на тестирование фреймворка чем тестирование вашего кода. Почему бы вам нужно проверить валидации?

Проверки в Rails действительно работают - на самом деле, в базе кода Rails есть модульные тесты, чтобы убедиться в этом. Когда вы проверяете валидацию модели, вы тестируете специфику валидации: длину, принятые значения и т. Д. Вы убедитесь, что код написан так, как задумано. Некоторые проверки являются простыми помощниками, и вы можете не проверять их на том основании, что «никто не может испортить вызов validates_numericality_of». Это правда? Каждый разработчик всегда помнит, чтобы написать это в первую очередь? Разве каждый разработчик случайно не удаляет строку из вставки плохой копии? По моему личному мнению, вам не нужно тестировать каждую последнюю комбинацию значений для помощника проверки Rails, но вам нужна строка, чтобы проверить, что она там с правильными значениями, переданными, на случай, если какой-нибудь панк изменит это в будущем без должного обдумывания.

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

Кроме того, тесты кажутся супер хрупкие к любым изменениям в вашем коде. Так если вы что-то измените в своих моделях, Вы должны изменить свои тесты и светильники, чтобы соответствовать. Разве это не нарушать принцип СУХОГО?

Я не верю, что это нарушает СУХОЙ. Они общаются (это то, что программирование, общение) две совершенно разные вещи. Тест говорит, что код должен что-то сделать. Код говорит, что он на самом деле делает. Тестирование чрезвычайно важно, когда между этими вещами есть разрыв.

Тестовый код и код приложения, очевидно, тесно связаны между собой. Я думаю о них как о двух сторонах монеты. Вы не хотели бы переднюю часть без задней части или заднюю часть без передней части. Хороший тестовый код усиливает хороший код приложения, и наоборот. Два вместе используются, чтобы понять всю проблему, которую вы пытаетесь решить. И хорошо написанный тестовый код является документацией - он показывает, как должен использоваться код приложения.

В-третьих, написание тестового кода, кажется, занимает много времени. Это нормально? не было бы это будет быстрее, чтобы обновить мой браузер и посмотреть, сработало ли это? я уже надо играть с моим приложение просто посмотреть, если оно течет правильно и убедитесь, что мой CSS не имеет взорвалось. Почему бы не ручное тестирование будет достаточно?

Вы работали только над очень маленькими проектами, для которых этого тестирования, возможно, достаточно. Однако, когда вы работаете над проектом с несколькими разработчиками, тысячами или десятками тысяч строк кода, точками интеграции с веб-сервисами, сторонними библиотеками, несколькими базами данных, месяцами разработки и изменениями требований и т. Д., Возникает много других факторы в игре. Ручного тестирования просто недостаточно. В проекте любой реальной сложности изменения в одном месте часто могут привести к непредвиденным результатам в других. Правильная архитектура помогает смягчить эту проблему, но также помогает автоматизированное тестирование (и помогает определить точки, в которых можно улучшить архитектуру), определяя, когда изменение в одном месте нарушает другое.

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

Я перечислю еще несколько преимуществ.

Если вы сначала протестируете (Test Driven Development), ваш код, вероятно, будет лучше. Я не встречал программиста, который дал бы ему хороший шанс, для которого это было не так. Сначала тестирование заставляет вас задуматься о проблеме и, на самом деле, разработать ваше решение, а не взломать его. Более того, это заставляет вас достаточно хорошо разбираться в проблемной области, чтобы, если вам действительно пришлось ее взломать, вы знаете, что ваш код работает в соответствии с заданными вами ограничениями.

Если у вас есть полный охват тестированием, вы можете выполнить рефакторинг без риска. Если проблема с программным обеспечением очень сложна (опять же, проекты в реальном мире, которые длятся месяцами, как правило, сложны), то вы можете упростить ранее написанный код. Итак, вы можете написать новый код, чтобы заменить старый код, и если он пройдет все ваши тесты, все готово. Он делает именно то, что делал старый код в отношении тестов. Для проекта, который планирует использовать метод гибкой разработки, рефакторинг абсолютно необходим. Изменения всегда должны быть сделаны.

Подводя итог, можно сказать, что автоматизированное тестирование, особенно разработка, основанная на тестировании, - это в основном метод управления сложностью разработки программного обеспечения. Если ваш проект не очень сложный, стоимость может перевесить выгоды (хотя я сомневаюсь в этом). Однако проекты в реальном мире, как правило, очень сложны, и результаты тестирования и TDD говорят сами за себя: они работают.

(Если вам интересно, я считаю, что статья Дэна Норта, посвященная поведенческому развитию, очень полезна для понимания большой ценности тестирования: http://dannorth.net/introducing-bdd)

Answer 2

Многие учебные пособия и примеры тестов, созданные генераторами Rails довольно отстойные и IMHO, которые могут создать ошибочное впечатление, что вы должны тестировать глупые вещи, такие как встроенные методы Rails и т. д.

Поскольку у Rails есть собственный набор тестов, нет смысла писать или запускать тесты, которые тестируют только встроенную функциональность Rails. Ваши тесты должны использовать код , который вы пишете! : -)

Что касается относительных достоинств выполнения тестов по сравнению с просто обновлением в вашем браузере. Чем больше становится ваше приложение, тем больше боли в заднице - приходится вручную выполнять многочисленные сценарии и крайние случаи, чтобы ничего не делать в вашем приложении сломался. В конце концов, вы прекратите тестирование всего приложения после каждого изменения и просто начнете «выборочное тестирование» в тех областях, которые, по вашему мнению, должны были быть затронуты. Неизбежно, вы найдете то, что раньше работало несколько месяцев назад, и теперь полностью сломано, и у вас нет уверенности, когда оно сломалось или какие изменения сломали его. После того, как это произойдет достаточно раз ... вы оцените автоматизированное тестирование ....: -)

Answer 3

Тесты должны проверять логику вашего приложения. Лично я считаю, что мои самые важные тесты - те, что я провожу в Selenium. Они проверяют, что то, что отображается в браузере, - это то, что я ожидаю увидеть. Однако, если это все, что у меня было, то мне было бы трудно отлаживать - это также помогает иметь тесты более низкого уровня, а интеграционные, функциональные и модульные тесты являются полезными инструментами. Модульные тесты позволяют вам проверить, что модель ведет себя так, как вы ожидаете (и это означает, что каждый метод, а не только валидация). Валидатины, безусловно, будут просто работать, но только если вы поймете их правильно. Если вы поймете их неправильно, они будут просто работать, но не так, как вы ожидали. Написание нескольких строк теста быстрее, чем отладка позже.

Простой пример, такой как http://wiseheartdesign.com/2006/01/16/testing-rails-validations, просто проверяет проверки в модульном тесте. Статья О'Рейли в http://www.oreillynet.com/pub/a/ruby/2007/06/07/rails-testing-not-just-for-the-paranoid.html?page=1 немного более полна (хотя все еще довольно проста).

Автоматическое тестирование особенно полезно в регрессионном тестировании, когда вы что-то меняете и запускаете набор тестов, чтобы убедиться, что вы больше ничего не сломали.

Тесты являются формой повторения, но они не нарушают DRY, потому что они выражают вещи по-другому. Тест гласит: «Я сделал X, чтобы Y произошло». Код говорит: «X произошло, так что теперь мне нужно сделать Z, что, в свою очередь, вызывает Y». т. е. тест стимулирует причину и проверяет следствие, а код реагирует на причину и воздействует на что-либо.

Answer 4

Все, что я читал об этом, показывает только проверки. Разве проверки в рельсах не должны работать? Это больше похоже на тестирование фреймворка, чем на тестирование вашего кода. Зачем вам нужно проверять проверки?

Есть хороший Railscast, показывающий один путь к тестовым контроллерам .

Answer 5

Например: Я работаю над проектом с 25000 строками (да, в rails 1.2), и в прошлый понедельник мне сказали, могу ли я заставить пользователей исчезать из каждого списка, кроме админских, если у них был установлен атрибут "left_date".

Вы можете переписать каждое действие списка (50+), чтобы поставить

@users.reject {|! У | Date.today> u.leave_date}

Или вы можете переопределить метод find (DRY ;-), но только если у вас есть тесты (для всего, что находит пользователей!), Вы будете знать, что ничего не сломали, переопределив User # find !!

Answer 6

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

Кроме того, написание тестов перед написанием кода (с использованием модели Test-Driven-Development) поможет вам писать код лучше и быстрее, поскольку тесты вынуждают вас полностью обдумать проблему. Это также поможет вам узнать, где разбить сложные методы на более мелкие, которые вы можете проверить по отдельности.

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