We seem to have a patch in place that allows fixtures to be loaded from
multiple directories. To do so, we have changed
Test::Unit::TestCase.fixture_path from a string to an array.
What is the justification for this? It looks like it’s there for
extension testing, but can’t extensions just provide their own
fixtures to provide enough data for what they want to test?
If we’re allowing extensions to use the core test data, then that test
data has become something published, and as such needs to be
kept in a backwards-compatible manner - do we want to take that on?
I just stumbled across this as I was trying to write a test for an
extension that calls ‘fixture_file_upload’ (part of rails core) -
that method expects that fixture_path is a string. I could extend the
patch to change the behaviour of ActionController::TestProcess
so that that will work, but that doesn’t mean that there aren’t plugins
out there that rely on fixture_path being in place that will
also be broken by that change.
Has anybody actually written an extension that needs this functionality
for its testing? If not, I’d like to just remove the
fixture_loading_extension.rb patch.
I can see your concern here, Dan. As a framework builder, one must be
careful about what he encourages folks to do.
At the same time, allowing access to aspects of the framework to the
end that users may go beyond the imaginings of the framework
designers is a very important part of framework design, IMO. To my
experience, these hooks are what allow the most advanced programmers
to go further. Again, I agree that we do not want to be in a position
where something like the Radiant test data is a form of public API. I
for one am quite willing to use that data at my own risk, recognizing
that should the time come that it changes, I will have a bit of work
to do. I don’t suppose a person would upgrade to a later version of
Radiant expecting to do no work
I have a friend who has said that making methods private is like
saying to all future users of the code, “I’m smarter than you - there
is no reason you should ever want to touch this”. Of course, I’m more
of the mind that private is a design tool, indicating more that, “I
can’t imagine right now why you would ever want to change this”. In
this frame of mind, I trust that Ruby will allow them work around my
shortsightedness ;), whereas a language like Java, half the
programmers using it don’t even begin to know how to invoke a private
method.
Anyway, we use the Radiant test data because it saves us a bunch of
time writing our own.
Yes, I have used it. In fact, I wrote that patch/extension. Are you
going to be at RailsConf? Maybe we can meet up and hack on some stuff.
No rails conf for me… Flights from Australia are a bit too expensive.
I think the main problem is that it changes the behaviour of an existing
method, rather than creating a new method.
I’ll have a look at introducing a fixture_paths accessor and have
fixture_path return the last path in that list to allow
compatability with anything that needs fixture_path as that’s probably a
cleaner solution than just hacking into
ActionController::TestProcess.fixture_file_upload to get it working
again.
The other impetus was to reduce the pain of moving from a regular
Rails app to developing an extension. In a lot of ways I feel this
method is less of a ‘hack’ than the special ‘extension_fixtures’
method that never quite felt right to me.
I just checked in a change to do that, but having the fixture_path
behave as base rails would probably be a good thing to make sure
that people don’t get tripped up by plugins that might use it.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
