При нормальных обстоятельствах подход будет использовать ваши тестовые данные для покрытия кода, но, как вы говорите, у вас есть части кода, которые тестируются, но не используются в производственном приложении, вы могли бы сделать что-то немного другое.
Для ясности: Не доверяйте автоматическим инструментам.Они будут показывать вам результаты только для тех вещей, которые вы активно тестируете, и ничего более.
С заявлением об ограничении ответственности я предлагаю вам использовать инструмент покрытия кода (например, rcov или simplecov для Ruby 1.9) в вашем производственном приложении и измерьте пути кода, которые фактически используются вашими пользователями.Хотя эти инструменты изначально были предназначены для измерения покрытия тестами, вы также можете использовать их для производственного покрытия
В предположении, что в течение периода тестирования пройдены все соответствующие пути кода, вы можете удалить остальные.К сожалению, это предположение, скорее всего, не будет полностью выполнено.Таким образом, вам все равно придется применять свои знания о приложении и его внутренней работе при удалении частей.Это еще более важно при удалении декларативных частей (например, ссылок на модели), так как они часто не выполняются напрямую, а используются только для настройки других частей системы.
Другой подход, который может быть объединен с вышеупомянутым, состоит в том, чтобы попытатьсяпреобразовать ваше приложение в выдающиеся функции, которые вы можете включать и выключать.Затем вы можете отключить функции, которые предположительно не используются, и проверить, никто не жалуется:)
И последнее замечание: вы не найдете волшебный инструмент для полного анализа.Это потому, что ни один инструмент не может знать, используется ли определенный фрагмент кода фактическими пользователями или нет.Единственное, что могут сделать инструменты, - это создать (более или менее) статические графы достижимости, сообщающие вам, вызван ли ваш код каким-либо образом из определенной точки.С динамическим языком, таким как Ruby, даже этого довольно трудно достичь, поскольку статический анализ не дает особого понимания перед метапрограммированием или динамическими вызовами, которые интенсивно используются в контексте рельсов.Поэтому некоторые инструменты фактически запускают ваш код или пытаются получить представление о тестовом освещении.Но магических заклинаний определенно не существует.
Так что, учитывая высокую внутреннюю (в основном скрытую) сложность приложения rails, вы не сможете обойтись без выполнения большей части анализа вручную.Лучшим советом, вероятно, будет попытка модульности вашего приложения и отключение определенных модулей, чтобы проверить, не используются ли они.Это может быть подтверждено соответствующими интеграционными тестами.