工厂女孩：创造与构建，需要不同的行为
我需要的是 Factory.define 块内的一种方法，以了解是否已使用 create 或 build 调用工厂，无论是显式还是简单地使用默认策略。
我有一个工厂，必须手动调整关联，代码的原始作者已经偏离了轨道，以至于可以管理正常的创建 barfs 和正常的构建。我不想在构建案例中调整这些关联，但我必须在创建案例中调整这些关联。
我一直在寻找是否有类似于“current_strategy”的东西，但我还没有看到任何东西。我知道我可以区分使用 after_create 和 after_build，但原作者这样做是为了在不进行调整的情况下保存对象的行为会导致巨大的不幸 - 在数据库中保存异常和垃圾。
我目前无权修复他编写的“模型”，现有的 rspec 测试使用差异随时做正确的事情。在每种情况下，先前的测试作者都选择从不使用创建，这意味着设置大部分测试数据是一个神秘而漫长的过程。
任何帮助将不胜感激 - 我仍在使用我的 GoogleFu，但希望短路...
哦，这是在 Rails 2 中（/cry），
谢谢！
What I need is a way inside a Factory.define block to know if the factory has been called using create or build, either explicitly or simply using the default strategy.
I have a factory that has to manually adjust associations that the original author of the code took so far off the rails that normal creation barfs and normal build can be managed. I don't want to adjust those associations in the build case, but I have to in the create case.
I've been looking to see if there is something analogous to 'current_strategy' but I haven't seen anything yet. I know I can distinguish using after_create vs. after_build, but the original author made it so that the act of saving the object without doing the adjustments causes massive unhappiness--save exceptions and garbage in the database.
I currently have no mandate to fix the "models" he wrote and the existing rspec tests use the differentiation to do the right thing at any time. In every case the prior test author(s) have opted to simply never use create, which means setting up most of the test data is an arcane and lengthy process.
Any help would be deeply appreciated--I'm still exercising my GoogleFu but would love to be short circuited...
Oh, this is in Rails 2 (/cry)
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这听起来确实是一个非常奇怪的问题，但既然你说你正在清理别人的代码，我会认为没有简单的方法来解决这个问题。
我不会从工厂方面来处理这个问题。工厂不应该关心，因为模型（不是工厂）应该是对象结构和关联方面有效性的看门人。
我会编写分别
创建和构建对象的规范，并测试它们的关联以确保它们是正确的（根据您想要的新行为 最终成为）。然后，通过重构模型来完成您实际需要它们做的事情，从而使这些规范通过。这就是清理遗留代码并改变其行为的方法 - 编写在新功能正确时将通过的测试，并重构直到它们通过，并在每次测试/重构中进行增量更改。当您的新规格通过后，您就大功告成了。如果前一作者提出了自己的规范来验证以前的行为，那么您将不得不努力找出这些测试中的哪些（如果有的话）当前有效（其中许多可能是有效的，因为它们代表了以下要求）该应用程序当前满足），并删除那些不满足的。
This sounds like a very strange problem indeed, but since you say that you're cleaning up someone else's code, I'll assume there's no easy way out of this.
I wouldn't approach this from the factory side. The factory shouldn't care because the model (not the factory) is supposed to be the gatekeeper of validity in terms of object structure and associations.
I would write specs that separately
createandbuildobjects, and test their associations to make sure they are correct (according to what you want the new behavior to ultimately be). Then, get those specs to pass by refactoring the models to do what you actually need them to do. This is how you clean up legacy code, and alter its behavior - write tests that will pass when the new functionality is correct, and refactor until they pass, making incremental changes with each test/refactoring.When your new specs are passing, you're well on your way. If the previous author put in specs of their own that verify the previous behavior, then you'll have to work on figuring out which, if any, of those tests are currently valid (many of them may be, since they represent the requirements that the app currently fulfils), and removing ones that aren't.