Em 24-04-2012 15:32, Don Morrison escreveu:
On Tuesday, April 24, 2012 at 11:11 AM, Rodrigo Rosenfeld Rosas wrote:
No, I start my specs with some populated data for some tables that
shouldn't change unless in some specific examples, but I'd like them
to rollback to the original state at the end of the examples. I do
really want to use savepoints instead of a truncate strategy or I'd
be already using DatabaseCleaner for that.
Your suggested approach wouldn't work pretty well as there are some
database constraints that would require a certain order in the tables
as well. This is pretty hard to maintain anyway and it is much slower
than "truncate table1, table2, ...".
Rodrigo,
It sounds like you need several "kinds" of tests. The speedy unit
tests can be done to exercise your code, objects, etc without the use
of the DB and some integration tests.
Yeah, but the problem is that this application will be comprised by
about 90% of integration tests and just a few unit tests as most of them
require accessing the database and making sure the correct queries are
being generated.
That is why I also need speedy integration tests.
To me, the tests you're talking about here are clearly integration
tests since you are writing data to the database. It also sounds like
you have some order dependent things happening.
I don't think this has any order dependency. What I'm trying to achieve
is a really common requirement. Please see other similar attempts:
https://github.com/pcreux/rspec-set
https://github.com/rspec/rspec-rails/issues/496
Basically we have a set of examples that need some initial data before
some actions. We have two options here.
1 - the commonest slowest one:
before(:each) { recreate_sample_data } # will be rolled back and
recreated for each example
2 - the fastest one, although I still don't know how to achieve this in
practice, but conceptually it is really simple:
before(:all) do
create_sample_data
create_savepoint
end
after(:all){ rollback_savepoint }
before(:each) {restore_save_point}
See? While 1 certainly works, 2 is much faster than 1.
The combination is difficult because it is a bad practice (in the eyes
of most test/spec advocates). Your tests really should be able to run
in any order - from expectation to expectation.
Yes, they should. I don't understand how what I'm trying to achieve
would change that.
Yes, I've realized that too. This makes it really hard to me to
manually create the savepoints by myself while still using Sequel
transaction support in the around(:each) block.
These save points could be emulated by creating fixtures (or factory
objects) that simulate things in the correct state then testing them.
Yes, that is what I'm currently doing, but that is much slower than what
I'm trying to achieve.
If you are trying to test state/savepoint transitions then start with
an object in state #1, move it to state #2 and then test. Going from
#1 to #2 to #3 probably isn't a good idea in a spec environment.
I don't need to test savepoints currently, but thank you.
Could you please give me some hint on how to achieve that with Sequel?
Again, the friction you are feeling is mostly likely due to straying
from the Golden Path(™) in tests/specs.
It might be enlightening if you posted a gist with your intended usage
and perhaps we could help from there.
If you still need a more in-depth Gist after the examples I gave in this
message let me know and I'll try to create one.
Cheers,
Rodrigo.
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
