Считается ли тестирование отношений в Rails лучшей практикой?

Интересно, считается ли тестирование отношений в Rails лучшей практикой или нет? У нас есть разногласия в команде по проверке отношений.

ИМО, это избыточно, т.е. каждый has_many :people должен быть протестирован с should have_many(:people), поскольку он выглядит повторяющимся, просто скопируйте-вставьте из модели в тест - т.е. я не могу представить, что он перестанет работать или какой-то другой рабочий процесс сломает его, единственный способ сломать его - просто удалить или изменить строку (но если кто-то просто случайно меняет код, кто-то также может просто удалить тест). Более того, он на самом деле не проверяет отношение (например, если компания возвращает людей, у которых есть соответствующие company_id, и если компания уничтожается - люди фактически уничтожаются - поскольку это может фактически потерпеть неудачу в случае проверки уничтожения или внешнего ключа), а просто проверяет, что отношение указано . И мы не проверяем, как этот класс отвечает на каждый отдельный метод, но если мы проверяем, мы проверяем, что делает метод.

Поскольку мы не тестируем другие статические вещи, такие как шаблоны (например, простой HTML без логики) — мы предполагаем, что рельсы будут генерировать указанный HTML, его невозможно сломать, если кто-то просто не изменит его.

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

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

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

заранее спасибо

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
0
58
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

В нашей компании мы не тестируем внутреннюю логику Rails. Мы не проверяем правильность обработки Rails has_many, belongs_to и т. д. Это стажерские вещи Rails, о которых вам не стоит беспокоиться.

Обычно у вас более чем достаточно других вещей для тестирования.

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

BenFenner 25.10.2022 16:44
Ответ принят как подходящий

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

Я не знаю о лучших практиках, но, по моему мнению, все, что может быть «толстым», должно быть проверено, включая отношения/ассоциации. Теперь вы хотите узнать, как избежать тестирования логики Rails, а вместо этого просто проверить, что отношение было настроено, но это несложно сделать.

Все наборы минитестов, в которые я вношу вклад, имеют тесты на наличие ожидаемых взаимосвязей/ассоциаций.

Опять же, идея состоит в том, что если кто-то случайно удалит или добавит один или два символа в эту строку кода, существует специальный тест для обнаружения этого. Не только это, но и преднамеренное удаление строки кода должно также включать преднамеренное удаление теста.

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

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

По моему мнению, это должно быть передовой практикой, и я не встречал особого протеста ни от одного из примерно дюжины других разработчиков Rails, с которыми я работал лично. И в более широком масштабе тот факт, что у shoulda-matchers есть специальные сопоставители для этого, означает, что есть достаточно других разработчиков, желающих получить эту возможность.

Вот мини-пример тестирования отношения/ассоциации без тестирования самой логики Rails:

  test 'contains a belongs_to relationship to some models' do
    expected = [:owner, :make].sort
    actual   = Car.reflect_on_all_associations(:belongs_to).map(&:name).sort

    assert_equal(expected, actual)
  end

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

Сопоставитель have_many не является частью rspec-rails. Скорее всего, это от должно-сопоставителей, которые можно использовать и с минитестом.

max 25.10.2022 22:40

Спасибо за информацию @max, я соответствующим образом отредактирую свой ответ.

BenFenner 26.10.2022 15:23

Другие вопросы по теме