Почему RSpec не навязывает поведение?

Question

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

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

Более того, допустим, у меня есть тест, в котором указано, что user.name должно быть либо Tom, либо John. Мои тесты работают отлично, потому что я указываю user.name внутри теста. Однако в реальном приложении может случиться, что имя станет «Алекс». Rspec не сможет навязать поведение, не так ли?

И я бы остался с прохождением теста, но с ошибкой.

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

(Опять же, я понимаю, что rspec может быть полезен, но как насчет вопросов, которые я здесь укажу?)

Answer 1

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

Answer 2

Я думаю, что если я добавлю проверку на модель, это приведет к ее поведению.

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

Поскольку я уже знаю, что скажу это, в чем смысл создания первого теста для него?В конце концов, он всегда будет проходить, если я не изменю валидацию (в этом случае я, конечно, это заметю).

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

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

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

Более того, допустим, что у меня есть тест, который указывает, что user.name должно быть либо«Том» или «Джон».

Этого недостаточно, чтобы быть хорошим тестом.Вы можете проверить, что «пользователь должен быть действительным, когда user.name имеет значение« Tom »» или «user.name должен быть включен в [« Tom »,« John »]» или даже «пользователь должен быть недействительным, если user.nameэто «Алекс».Вы не можете надеяться написать тест для всех возможных входов в ваше приложение, поэтому вам нужно сделать разумный выбор в отношении того, что тестировать.Проверьте, что действительные входные данные дают действительные результаты.Проверьте, что неверные данные не пройдены ожидаемым образом.Не беспокойтесь о проверке всех возможных недопустимых вводов или недопустимого использования вашего кода.

Если для «user.name» недопустимо быть «Alex», возможно, вам следует проверить, что код вызывает вашего пользователя.объект не пытается установить свое имя в "Алекс".Если «Alex» является допустимым именем, но ваш код все равно не удался, вам следует написать более надежный код, более качественные тесты и тест для имени «Alex», чтобы убедиться, что вы исправили свой класс User для обработки этого имени.

Пожалуй, самое главное, если вы сначала пишете тесты, то они могут заставить вас разработать лучший интерфейс для вашего класса User.Тот, который более четко выражает поведение атрибута «name» и не рекомендует устанавливать недопустимые имена.

Answer 3

Тесты есть тесты.Они проверяют вещи.Они не навязывают вещи.

Они полезны, потому что вы можете видеть, что работает, а что нет в вашем приложении.Когда вы переопределяете этот name= установщик, чтобы сделать что-то необычное, и это нарушает простой случай, для которого вы написали тест, этот тест просто спас вашу задницу.Для таких простых случаев, как это, можно обойтись без теста.Очень редко 100% тестовое покрытие встречается в приложениях с открытым исходным кодом.До тех пор, пока вы не узнаете, что вам не нужно тестировать, проще всего написать тесты для всего, что вы можете.

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