ruby - A Rails 3 Engine-Gem which is Also an Application wants to share a DRY configuration via Mixin -

i have number of engines gems , applications (rails3). gems can installed , dependencies managed via bundler in more 1 application (its whole stack upon multiple applications built). engines take advantage of rails resources - models , such. applications 2 reasons: 1) provide full testing environment isolated including applications can 'rails c' example , 2) in order run things 'rake db:migrate' , seed , more.

i want both engine , application inject mixins lower level dependencies. here solution came with. works fine - wondering if has criticisms of approach or best practice share regarding sharing issue or overall idea of engine-gem-applications:

the engine:

#my_engine/lib/my_engine.rb require 'my_engine/config.rb' module myengine   class engine < rails::engine     config.to_prepare       myengine.inject_mixins     end   end end 

the application:

#my_engine/config/application.rb require 'my_engine/config' module myengine   class application < rails::application     config.to_prepare       myengine.inject_mixins     end   end end 

the mixin:

#my_engine/lib/my_engine/config.rb module myengine   module classmethods     def inject_mixins       ::applicationhelper.send(:include, myengine)       ::somedependency::someclass.send(:include, myengine::someclassmixin)     end     #root should defined root of engine, ie relative file      def root       file.join(file.dirname(__file__), '..','..')     end   end extend class_methods end 

(update: edited above wrap module in my_engine module, otherwise more 1 engine using pattern simultaneously have unpredictable effects, myengine.root == someotherengine.root)

there's no rhyme or rule this, have couple different options.

your gem's tests can contain dummy application testing. devise this, example. accepted practice gems heavily rails-dependent.

you can keep separate. in past i've set testing application gemfile points gem via path (gem 'mygem', :path => 'some/path'), makes testing relatively easy. can double sample application can provide in separate repository (keep in mind when tagging gem should change sample application's :path parameter specific version). benefit here sample application kept date.

if you're talking unit testing models, can skip above , add testing dependency on active record , sqlite. keep fixture data gem.

since have several of these engines , mixed , matched in different applications, suggestion set application uses of these gems , serves functional testbed. keep unit tests individual gems, of course. has added benefit of integration testing between engines, ensure there no conflicts.