Ruby on Rails - зачем использовать тесты?
6 ответов
не был Должен проверки в направляющих просто работать? Это больше походит на тестирование платформы, чем тестирование Вашего кода. Почему необходимо было бы протестировать проверки?
проверки в направляющих действительно работают - на самом деле, существуют модульные тесты в кодовой базе направляющих для обеспечения его. При тестировании проверки модели Вы тестируете специфические особенности проверки: длина, принятые значения, и т.д. Вы удостоверяетесь, что код был написан, как предназначено. Некоторые проверки являются простыми помощниками, и можно решить не протестировать их на понятии, что "никто не может испортить validates_numericality_of вызов". Это верно? Каждый разработчик всегда не забывает писать это во-первых? Каждый разработчик случайно никогда не удаляет строку на плохой вставке копии? По моему личному мнению Вы не должны тестировать каждую последнюю комбинацию значений для помощника проверки направляющих, но Вам нужна строка для тестирования этого, это там с правильными переданными значениями, на всякий случай некоторый панк изменяет его в будущем без надлежащей предусмотрительности.
Далее, другие проверки более сложны, требуя большого количества пользовательского кода - они могут гарантировать более полное тестирование.
, Кроме того, тесты кажутся супер хрупкими любому изменению в Вашем коде. Таким образом, при изменении чего-нибудь в моделях необходимо изменить тесты и приспособления для соответствия. Разве это не нарушает принцип DRY?
я не полагаю, что это нарушает DRY. Они связываются (это - каково программирование, коммуникация), две совсем других вещи. Тест говорит, что код должен делать что-то. В коде говорится, что он на самом деле делает. Тестирование чрезвычайно важно, когда существует разъединение между теми вещами.
Тестовый код и код приложения глубоко связаны, очевидно. Я думаю о них как две стороны монеты. Вы не хотели бы переднюю сторону без спины или спины без передней стороны. Хороший тестовый код укрепляет хороший код приложения, и наоборот. Два вместе используются для понимания целой проблемы, которую Вы пытаетесь решить. И правильно написанный тестовый код является документацией - это показывает, как код приложения должен использоваться.
В-третьих, пишущий тестовый код, кажется, занимает много времени. Это нормально? Это только было бы быстрее, чтобы обновить мой браузер и видеть, работало ли это? Я уже должен играть со своим приложением только, чтобы видеть, течет ли оно правильно, и удостоверьтесь, что мой CSS не взорвался. Почему ручное тестирование не было бы достаточно?
Вы только работали над очень маленькими проектами, для которых то тестирование возможно достаточно. Однако, когда Вы работаете над проектом с несколькими разработчиками, тысячами или десятками тысяч строк кода, точек интеграции с веб-сервисами, сторонними библиотеками, несколькими базами данных, месяцы разработки и изменений требований, и т.д., существует много других факторов в игре. Ручное тестирование достаточно просто. В проекте любой реальной сложности изменения в одном месте могут часто иметь непредвиденные результаты в других. Надлежащая архитектура помогает смягчить эту проблему, но автоматизированное тестирование помогает также (и помогает определить точки, где архитектура может быть улучшена) путем идентификации, когда изменение в одном месте повреждает другого.
Моя проблема состоит в том, что затраты на запись тестов кажутся нелепо высокими по сравнению с преимуществами. Тем не менее любой подробный ответ приветствуется, потому что я, вероятно, пропустил преимущество или два.
я перечислю еще несколько преимуществ.
, Если Вы тестируете первый (Разработка через тестирование), Ваш код, вероятно, будет лучше. Я не встретил программиста, который дал ему твердый выстрел, для кого это не имело место. Тестирование сначала вынуждает Вас думать о проблеме и на самом деле дизайн Ваше решение, по сравнению с вырубанием его. Далее, это вынуждает Вас понять проблемную область достаточно хорошо туда, где, если действительно необходимо вырубить его, Вы знаете свои работы кода в рамках ограничений, Вы определили.
, Если у Вас есть полное тестовое покрытие, можно осуществить рефакторинг без РИСКА. Если программная проблема очень сложна (снова, проекты реального мира, которые длятся в течение многих месяцев, имеют тенденцию быть сложными), затем, можно хотеть упростить код, который был ранее написан. Так, можно написать новый код для замены старого кода, и если он проходит все тесты, Вы сделаны. Это делает точно, что старый код сделал относительно тестов. Для проекта, который планирует использовать метод гибкой разработки, рефакторинг абсолютно необходим. Изменения должны будут всегда вноситься.
Таким образом, автоматизированное тестирование, особенно разработка через тестирование, является в основном методом управления сложностью разработки программного обеспечения. Если Ваш проект не очень сложен, стоимость может перевесить преимущества (хотя я сомневаюсь относительно этого). Однако проекты реального мира имеют тенденцию быть очень сложными, и результаты тестирования и TDD выступают за себя: они работают.
(Если Вам любопытно, я нахожу статью Dan North о Поведении Управляемой Разработкой, чтобы быть очень полезным в понимании большого количества значения в тестировании: http://dannorth.net/introducing-bdd )
Тесты должны проверить Вашу прикладную логику. Лично, я думаю, что мои самые важные тесты - те, я работаю в Селене. Они проверяют, что то, что обнаруживается в браузере, на самом деле, что я ожидаю видеть. Однако, если бы это - все, что я имел, затем мне было бы трудно отладить - это помогает иметь более низкие тесты уровня также и интеграцию, функциональную, и модульные тесты являются всеми полезными инструментами. Модульные тесты позволяют Вам проверить, что модель ведет себя способ, к которому Вы ожидаете это (и который означает каждый метод, не просто validatins). Validatins будет, конечно, Просто Работать, но только если Вы разбираетесь в них. Если Вы поймете их превратно, то они будут Просто Работать, но не способ, которым Вы ожидали. Запись нескольких строк теста более быстра, чем отладка позже.
А простой пример как тот в http://wiseheartdesign.com/2006/01/16/testing-rails-validations просто проверки проверок в модульном тесте. Статья O'Reilly в 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 происходить". т.е. тест стимулирует причину и проверяет эффект, в то время как код отвечает на причину и производит что-то.
Я действительно не использовал направляющие очень, но я думал бы, что эти автоматизированные тесты будут полезны как испытания с помощью дыма, чтобы быть уверенными, что вещь, которую Вы просто сделали, не повреждает что-то, что Вы сделали на прошлой неделе. Это станет все больше важным, когда Ваш проект растет.
кроме того, пишущий тесты перед написанием кода (использующий модель Test-Driven-Development) поможет Вам написать код лучше и быстрее, так как тесты вынуждают Вас полностью продумать проблему. Это также поможет Вам знать, где разбить сложные методы в меньшие методы, которые можно протестировать индивидуально.
Вы правы, писание и поддержание тестов занимают много времени. Иногда больше времени, чем сам код. Однако это может сэкономить Вам время в устранении ошибки и осуществляющий рефакторинг по причинам выше.
Например: Я работаю над проектом с 25000 строками (да, в rails 1.2), и в прошлый понедельник мне сказали, могу ли я заставить пользователей исчезать из каждого списка, кроме админских, если у них был установлен атрибут "left_date" в прошлом.
Вы можете переписать каждое действие списка (50+), чтобы поместить
@ users.reject! {| u | Date.today> u.leave_date}
Или вы можете переопределить метод "find" (DRY ;-), но только если у вас есть тесты (для всего, что находит пользователей!), Вы будете знать, что ничего не сломали переопределение User # find !!
Многие учебные пособия и примеры тестов, созданные генераторами Rails , довольно слабые и ИМХО, что может создать ошибочное впечатление, что вы должны тестировать глупо такие вещи, как встроенные методы Rails и т. д.
Поскольку у Rails есть свой собственный набор тестов, нет смысла писать или запускать тесты, которые тестируют только встроенную функциональность Rails. Ваши тесты должны использовать код , который вы пишете ! : -)
Что касается относительных достоинств выполнения тестов по сравнению с просто обновлением в вашем браузере. Чем больше становится ваше приложение, тем больше боли в заднице, которую приходится выполнять вручную через многочисленные сценарии и крайние случаи, чтобы убедитесь, что ничего в вашем приложении не сломалось. В конце концов, вы После каждого изменения я перестану тестировать все ваше приложение и просто начну «выборочное тестирование» в областях, которые, по вашему мнению , должны были быть затронуты. Неизбежно, вы найдете то, что раньше работало несколько месяцев назад, и теперь полностью сломано, и у вас нет уверенности, когда оно сломалось или какие изменения сломали его. После того, как это произойдет достаточно раз ... вы оцените автоматизированное тестирование ....: -)
Все, что я прочитал об этом, просто показывает проверки тестирования. Разве проверки в рельсах не должны работать? Это больше похоже на тестирование фреймворка, чем тестирование вашего кода. Зачем вам нужно проверять валидации?
Есть хороший Railscast, показывающий один способ тестировать контроллеры .
dynamic_castочень тесны.:-P Просто играют с ним самостоятельно, пока Вы не приобретаете навык его.:-) – Chris Jester-Young 13 February 2010 в 02:16