Posts [ 11 ]

Topic: Fixtures with No Underlying DB

I know this should be simple, but I have a bunch of forms that simply don't store data but rather email their contents to the appropriate recipients. The forms dupe AR into doing validations, but when I get to testing (I know it should be first), I can't quite get things rigged right because all I want to do is load data from a fixture to toss good and broken info at the model.

Rails tests try to load fixtures into a database table, but as I've explained, in my case there isn't one. Any thoughts about how best to test things like this?

Re: Fixtures with No Underlying DB

It seems like this "non-inserted" fixture use-case is one of the less universal, but still rather common, requirement in testing. It would be nice if there were some convention in Rails to handle it. Either some annotation in YAML that would cause the fixture to be instatiated, but not inserted or some supplementary file fixtures/<model>_nonDB.yaml, etc.

Both model and controller tests tend to want to have a "stock" good but not inserted fixture to work with to test the successful paths, as well as allowing for programmatic mutations to create known failing cases.

Re: Fixtures with No Underlying DB

Why use AR... let me count the reasons...

Clients change their minds and say, "would you mind storing that information"?All the validations that don't exist for plain old Ruby objects are already in place. And they're tested The errors collection interfaces nicely with the field highlighting. And it's tested

This isn't as warped a use of AR as it might seem. I've had several recent requests to, as I said, turn a form from entry-to-email into entry-to-database with email ping. And don't I seem just a bit brighter for having considered that possibility?

I agree with NielsenE that this is a use-case that occurs enough to warrant some attention. Rails Recipes publishes a way to stub out certain AR methods to get validations in this way, but doesn't talk about testing.

Would one have to come up with a patch to get something considered for core?

Re: Fixtures with No Underlying DB

I don't agree. Active Record is an Object Relational Mapping tool. Changing it to support anything else would add unecessary complication to the code base. For example, how would you handle "validates_uniqueness_of"? It breaks the whole paradigm.

It would be cool to be able to load fixtures into non AR objects, and I'm sure there's a way to do it. But using Active Record without a database, and loading fixtures into a sans db AR object just seems like asking for trouble.

Re: Fixtures with No Underlying DB

cwd wrote:

Why use AR... let me count the reasons...

Clients change their minds and say, "would you mind storing that information"?All the validations that don't exist for plain old Ruby objects are already in place. And they're tested The errors collection interfaces nicely with the field highlighting. And it's tested

This isn't as warped a use of AR as it might seem. I've had several recent requests to, as I said, turn a form from entry-to-email into entry-to-database with email ping. And don't I seem just a bit brighter for having considered that possibility?

No, I consider it premature optimization. Get your app to do what it needs to do NOW in the simplest way. Worry about future functionality in the future once it's been decided on.

Re: Fixtures with No Underlying DB

Both sides have a lot of merit here...

vin's point about the "simplest thing that works" is very important -- however in Rails, leveraging AR for a lot of non-DB tasks is seen by some as the simplest thing and thus there is the constant push of the square peg into a round hole.

Now given Ruby's flexible nature, I suspect it should be possible to mixin some of the validation and object creation methods into a non-AR class and thus have a validateable class that doesn't expect the rest of the AR infrastructure. (Some validations, such as uniqueness_of, as mentioned above don't make sense across such a mixin, though)

If the validation aspect is hard to seperate from the AR aspect, it might be worth talking to core about possible refactorings that would be acceptible to them to make the validations more re-useable outside the context of an AR.

(This doesn't directly address the non-inserted fixture topic, which has uses even when a "normal" AR is being used.)

Re: Fixtures with No Underlying DB

vin wrote:

No, I consider it premature optimization. Get your app to do what it needs to do NOW in the simplest way. Worry about future functionality in the future once it's been decided on.

But from my perspective the simplest thing to do is not write code that performs common validations. I like the stuff that's there just fine. I really don't see this as optimizing much beyond me repeating myself. How is using AR for this seems like an optimization?

There might be some goodness associated with using the AR::Validations mixin and stubbing out the parts that rely on a database but I'm not sure why that would be simpler than just using AR.

Re: Fixtures with No Underlying DB

What vin is saying is that using "Clients change their minds and say, "would you mind storing that information"?" as one of your reasons for using AR without a database is premature. IMO, too many developers, including myself say, "well what if the client asks for this?". Certainly there are sometimes where it makes sense. However, if you're fairly certain they're going to ask for it, why not just do it? Otherwise it can always wait.