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. Dan.
on 2007-05-10 08:35
on 2007-05-10 14:39
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. Sean
on 2007-05-10 16:09
We've recently used it as well. 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. aiwilliams
on 2007-05-10 21:46
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. Sean
on 2007-05-11 01:21
> 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. Dan.
on 2007-05-11 01:32
I'll also look into the fixture_file_upload to see if it could use some similar logic to the create_fixtures. Sean
on 2007-05-11 02:34
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.