def test_my_case
assert_efficient_sql do
# just wrap them in this block!
end
end
The assertion intercepts and copies out your MySQL SELECT statements, then
calls EXPLAIN on each one, and inspects the results for common problems.
The goal is test cases that resist database pessimization, even as you change
your data relations, to add new features. If you run your tests after
every few changes, you can easily detect which change broke your database's
indices and relations.
def test_my_case
assert_efficient_sql do
# just wrap them in this block!
end
end
This looks very interesting! I do have one reservation, which
basically boils down to 'the test database is very small'.
For example my customer fixtures define a dozen or so customers
whereas obviously the production version contains a hell of a lot
more. So no matter what I do in my code, I'm unlikely to hit
the :throttle limit. Is it not also the case that mysql might choose a
different query plan depending on index statistics etc... which are
likely to be profoundly different in the production (or even
development) databases ?
I imagine one could lean on this to produce some sort of continuous
integration system which would test core 'routes' through the system
for regressions in this area
