Модульные тесты для сторонних библиотек

Question

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

Мне интересно, нужно ли / полезно ли написание юнит-тестов для этих библиотек или нет. Например, я только что интегрировал friendly_id вокруг одной из своих моделей. Помимо установки гема и добавления его в качестве зависимости проекта, эта степень интеграции составила:

has_friendly_id :name

Это просто сработало, и я едва ли считаю это «кодом, который я написал». Так что я должен писать в виде тестов?

На мой вопрос есть две оговорки:

1. Я предполагаю, что все мои сторонние библиотеки имеют соответствующие собственные тесты, и поэтому написание новых модульных тестов непосредственно для этих библиотек выглядит как повторяющийся код. (Если бы мне пришлось использовать плохо протестированную библиотеку, я бы с меньшей неохотой писал ее тесты.)
2. В разделе Defect-Driven-Testing я обязательно напишу тест, как только столкнусь с проблемой. Если бы тест выявил ошибку в библиотеке, то я, вероятно, отправил бы тест сопровождающему.

Кроме этого ... есть ли смысл проверять сторонний код?

Answer 1

Это не нормальная практика для модульного тестирования кода другой стороны. Как правило, вы доверяете своим зависимостям вверх по течению для правильной работы.

Но это при условии, что вы действительно им доверяете. Есть много причин, по которым это должно сломаться.

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

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

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

Answer 2

Никогда не доверяйте сторонним библиотекам. Я всегда пишу набор тестов, которые я называю «проверками работоспособности» для сторонних библиотек, но я применяю его только к одной модели / контроллеру / любому другому. Так, например, если я использую гем act_as_paranoid (который делает записи базы данных выглядящими удаленными, но фактически не удаляет их), я напишу набор тестов для только для одной моделей, использующих расширение, и Предположим, что это работает для остальных из них. Это позволяет мне спать по ночам, зная, что я могу обновлять гем, когда выйдут новые версии, или даже использовать «крайнюю» версию, и ожидаемая функциональность будет надежной.

Answer 3

Вот мои мнения, основанные на опыте:

• Не проверяйте сторонние библиотеки в своем веб-приложении. Разветвите их, убедитесь, что они тестируются внутри себя и зависят от вашего форка (или версии, коммита или тэга), пока вы не будете готовы перейти на следующую версию. Если вы обнаружите ошибки, внесите изменения в свой форк и отправьте запрос на извлечение в официальный репозиторий. Пока ошибки не будут выведены в основную линию, используйте собственную вилку.
• Создание слоя адаптера (модуля или класса, который вызывает стороннюю службу) - отличная идея, но она лучше подходит для библиотек или гемов, чем для кодовых баз веб-приложений. Хорошая особенность адаптеров заключается в том, что вы можете сделать их Mock-версию для загрузки только в среде тестирования.
• Смоделируйте внешние вызовы http, используя WebMock, FakeWeb, Artifice или ..., и этот список можно продолжить. Убедитесь, что вы сказали утилите не разрешать внешние вызовы в тестовой среде.
• Может быть, использовать видеомагнитофон для записи и макетирования всех http-запросов при последующих тестовых запусках (Одно предупреждение о видеомагнитофоне - это очень полезно, но будьте осторожны при использовании его стратегии автоматического присвоения имен кассетам с большей кодовой базой - любые изменения в масштабах всего приложения сделает большинство ваших автоматически сгенерированных кассет бесполезными. Если вместо этого вы просто используете блоки VCR.use_cassette('cassete-name') do, это должно быть очень похоже на использование WebMock / Fakeweb / Artifice и т. д. Последнее - мое предпочтение.)

Answer 4

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