Лучший способ добавить тесты в существующий проект Rails?

Question

У меня есть проект Rails, для которого я пренебрегал для создания тестов (к стыду!), И база кода стала довольно большой. Мой друг сказал, что использовать RSpec было бы трудно, если вы не используете его с самого начала. Это правда? Что заставит его сказать это?

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

Answer 1

Этот вопрос недавно появился в списке рассылки RSpec, и совет, который мы обычно давали, был:

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

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

Я бы также рекомендовал вам использовать встроенную задачу rake spec: rcov для генерации статистики покрытия кода. Очень приятно наблюдать, как эти цифры растут, когда вы начинаете тестировать свою кодовую базу.

Answer 2

Может начать с моделей? Они должны быть проверены в изоляции, что должно сделать их фруктами с самым низким висянием.

Затем выберите модель и начните писать тесты, которые говорят, что она делает. По ходу дела подумайте о других способах тестирования кода - есть ли крайние случаи, в которых вы, возможно, не уверены? Напишите тесты и посмотрите, как ведет себя модель. По мере разработки тестов в коде могут появляться области, которые не настолько чисты и не дублированы (DRY), как они могут быть. Теперь у вас есть тесты, вы можете реорганизовать код, поскольку вы знаете, что не влияете на поведение. Старайтесь не начинать улучшать дизайн, пока у вас не появятся тесты - в этом и заключается безумие.

Как только вы закрепите модели, двигайтесь вверх.

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

Answer 3

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

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

Answer 4

Принятый ответ - хороший совет, хотя в некоторых случаях это не практично. Недавно я столкнулся с этой проблемой в нескольких моих приложениях, потому что мне НУЖНЫ тесты для существующего кода. Другого пути просто не было.

Я начал выполнять все модульные тесты, затем перешел на функционалы.

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

Используйте rcov для измерения вашего прогресса.

Удачи!

Answer 5

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

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

Одной из идей было бы начать с тестов с полным стеком, используя что-то вроде раннера RSpec. Затем вы можете работать извне, изолируя то, что вы можете в низкоуровневых изолированных тестах, и постепенно постепенно распутывать сложный код.

Answer 6

Вы можете начать писать «тесты характеристик». С этим вы можете испытать вычурный камень здесь :

Это все еще в стадии разработки.