Rails: Хороший процесс для добавления тестов задним числом?

Question

У меня есть несколько приложений, к которым я хотел бы вернуться и задним числом создать набор тестов (RSpec & Cucumber), но начать этот процесс немного сложно.

Что бываш процесс для возврата к существующему приложению и создания набора тестов для него?

Answer 1

Сначала я бы добавил тесты высокого уровня (огурец).Это придаст вам уверенности, что поведение не изменится незамеченным.Я бы не стал добавлять rspec-тесты (или, может быть, просто несколько важных), потому что вы, вероятно, тоже захотите много реорганизовать. MetricFu недавно получил метрику под названием «HotSpots», которая объединит другие метрики и укажет на самые большие проблемы в коде.Эти места обычно также наиболее важны для вашего приложения.Исправьте их так, чтобы их можно было прочитать, и вы получите представление о том, о чем идет речь.Пока не переусердствуйте.

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

Answer 2

Я недавно начал заниматься добавлением тестов в кучу старого кода, и я обнаружил, что он очень полезен: rcov (я не беспокоюсь о плагине rcov rails и просто cd для тестирования и запускамаленький сценарий оболочки, который запускает rcov с правильными исключениями и открывает отчет, если все тесты пройдут.) Затем я начал работать с теми из них, которые были близки к 100% охвату, и просто обрабатывал проценты по крупицам.Это гораздо более ощутимый прогресс, чем: «Тьфу, с чего начать с добавления тестов для этого?!»

Answer 3

Я немного не в теме, но в любом случае ...

Я думаю, что модульное тестирование моделей в рельсах (минимум 3) бесполезно ... Я имею в виду, особенно когда коднаписано, значит ты не делаешь TDD.Вы хотите проверить свою валидацию?Зачем ?Просто прочитайте код, и вы сами обнаружите ошибки.Я говорю, что rails обеспечивает (в некоторых местах) такой человеческий синтаксис, что было бы стыдно его тестировать.

На мой взгляд, такой синтаксис сам по себе является спецификацией .Тогда зачем писать тест?

И чтобы было ясно: нет, я не говорю, что тестирование бесполезно все время.Я не работаю в каком-то случайном веб-агентстве ...: p

Answer 4

В последнее время я много занимался этим для клиентских проектов.Самыми большими блоками для меня, кажется, является безудержное использование встроенного JavaScript с или без RJS.[Примечание: есть правильный и неправильный способ сделать AJAX, и большинство людей делают Doing It Wrong ™.] Обычно я использую огурец с небольшим количеством rspec для странных модульных тестов.

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

Если вас это не устраивает или у вас уже есть набор модульных тестов, и вы хотите добавить интеграцию, следующий вопрос - это степень, в которой вы выполняете много встроенного JavaScript или RJS,Если ваше приложение очень «ajaxy», вам нужно начать с драйвера селена для огурцов, который в феврале работает медленнее, чем патока, но он справится с работой.Как только у вас будет набор тестов, охватывающих всю функциональность (или даже только важные вещи) для вашего приложения, я начну рефакторинг javascript, чтобы он работал ненавязчиво.

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

Важно помнить, что не все должно происходить в одночасье.Проанализируйте свои рабочие процессы (например, вход в систему, выполнение задачи A, выполнение задачи B и т. Д.) И определите, какие из них покрывают 80% ваших типичных случаев использования.Проверьте это в первую очередь.Затем используйте что-то вроде metric_fu или просто rcov (или любой другой инструмент покрытия) и найдите области вашего кода, которые логичны и не проверены.Мне нравится metric_fu за это, потому что набор инструментов, которые он запускает, может дать вам обе эти части информации.