Wrapping mail generation in rolled-back transaction to prevent database changes from persisting

[costa]

I use factories for specs and I find them very convenient to use in mail_view's "actions".
Factories — as well as other methods for generating sample data on the fly — need to be cleaned after.
Since mail_view is supposed to be read-only, I see no disadvantage in actual prevention of data changes persistency — using transactions.

The first commit is kinda working draft for discussion, I'll add specs+docs if needed.

p.s. I've seen #69 but did neither like the solution nor understand the discussion there.

slightly-off-topic: Might be useful to include in the docs: mail_view for human — and also for automatic — testing.

[Zeneixe]

Will you guys ever integrate this in ActionMailer? It's pretty useful

[jeremy]

This would need to be within the transaction, before rollback.

[costa]

Thanks

[jeremy]

It's a nice idea. It's simple in the common case, but breaks down at the edges. Considering that seed data handles these cases nicely, or using MyModel.new without saving, there isn't great pressure to introduce an automatic transaction rollback.

[costa]

@jeremy Seed data? Using any other form of protection is great, but less convenient, that's the point of this discussion.