Factory Girl: создать против сборки, нужно другое поведение

Question

Мне нужен способ внутри блока Factory.define, чтобы узнать, была ли вызвана фабрика с использованием create или build, явно или просто с использованием стратегии по умолчанию.

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

Я искал, чтобы увидеть, есть ли что-то аналогичное 'current_strategy', но я не сделалеще ничего не видел.Я знаю, что могу отличить использование after_create от after_build, но первоначальный автор сделал это так, что сам процесс сохранения объекта без внесения корректировок вызывает огромное несчастье - сохранение исключений и мусора в базе данных.

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

Любая помощь будет высоко оценена - я 'Я все еще использую свой GoogleFu, но хотел бы, чтобы было короткое замыкание ...

О, это в Rails 2 (/ cry)

спасибо!

Answer 1

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

Я бы не подошел к этомус заводской стороны.Фабрика не должна заботиться, потому что модель ( не фабрика ) должна быть привратником валидности с точки зрения структуры объекта и ассоциаций.

Я бы написал спецификации, которые отдельно create и build объектов, и проверьте их ассоциации, чтобы убедиться, что они правильные (в соответствии с тем, что вы хотите, чтобы новое поведение в конечном итоге было).Затем заставьте эти спецификации пройти, сделав рефакторинг models , чтобы сделать то, что вам действительно нужно.Вот как вы очищаете унаследованный код и изменяете его поведение - пишите тесты, которые пройдут, когда новые функциональные возможности будут правильными, и рефакторинг, пока они не пройдут, внося постепенные изменения с каждым тестом / рефакторингом.спецификации проходят, ты уже в пути.Если предыдущий автор ввел свои собственные спецификации, которые проверяют предыдущее поведение, то вам нужно будет выяснить, какие из этих тестов, если таковые имеются, являются действительными в настоящее время (многие из них могут быть, так как они представляют требования, которыеприложение в настоящее время выполняет), и удаляя те, которые не являются.