Какая польза от написания тестов, совпадающих с конфигурационным кодом, построчно?

Question

Мне было интересно узнать о полезности написания тестов, которые поочередно соответствуют коду.

Просто пример: в Rails вы можете определить 7 маршрутов отдыха в одной строке в rout.rb, используя:

resources :products

BDD / TDD предписывает сначала выполнить тестирование, а затем написать код.Чтобы проверить весь эффект этой строки, разработчики придумали макросы, например, для musta: http://kconrails.com/2010/01/27/route-testing-with-shoulda-in-ruby-on-rails/

class RoutingTest < ActionController::TestCase
  # simple
  should_map_resources :products
end

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

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

Когда я спрашиваю, люди отвечают мне, что:

"тесты должны документировать ваш кодтак что да, имеет смысл написать их, даже если это всего лишь одна строка, соответствующая одной строке "

Что вы думаете?

Answer 1

Стоит заглянуть под капот, чтобы увидеть , что на самом деле делает макрос musta . Он проверяет каждый маршрут, сгенерированный resources :products, то есть он не просто проверяет наличие оператора resources в файле маршрутов. Так что это на самом деле не пример тестирования кода Rails, который уже был протестирован.

Answer 2

В Rails уже есть тесты для маршрутизации DSL. Единственное преимущество макроса в том, что он проверяет, действительно ли вы включили объявление в файл маршрута, который должен быть неявно проверен с помощью набора интеграционных тестов.

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

Надеюсь, это поможет.

Answer 3

Как говорит мой босс (кстати, он тоже кодер), это хорошие примеры тестирования, но иногда вам просто нужно знать, что тестировать. В вашем случае проверка работоспособности рельсов - это хорошо, но, как мы все знаем, она уже проверена. Нам не нужно писать тесты для этого.

В нашем цикле разработки мы используем тесты только для тех вещей, которые не являются простыми / сложными / уже протестированы. Скажем, у вас есть прикрепление скрепки к модели. Мы не проверяем, подключен ли он уже, есть тест для того, что уже сделано специалистами по скрепке. Вы проверяете, может ли ваша модель получить доступ к этому вложению или процессу, в котором вы его прикрепили, или к чему-либо еще.

Нечто подобное :) Надеюсь, это имеет смысл

Answer 4

Для меня это хорошая практика, чтобы избежать большой ошибки.

Например, после слияния или редактирования этот ресурс удаляется. Как узнать это?

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

Answer 5

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

Answer 6

Не думаю, что вам следует явно что-то тестировать.

Когда страница отображается в тесте, form_for будет жаловаться, что маршрут не существует. А потом я добавляю это. И если это путь ресурсов или именованный маршрут, это не имеет значения, на мой взгляд. Впоследствии, когда существует несколько именованных маршрутов, вы можете реорганизовать файл маршрутов, чтобы использовать ресурсы вместо нескольких именованных маршрутов.